Once I get time to finish #337, this will happen.

Originally posted by @westes in #412 (comment)

This is the single open issue in the 2.6.5 milestone and 18 items were already closed in the 2.6.6 milestone [although I'm not sure if they were "just closed" without any actual commit, in this case those should be adjusted to have no milestone attached].

As there obviously is no "release often" happening - can we please have the 2.6.5 release (now containing changes of nearly 4 years) done "at least this time" manually?

I'm getting the hang of scripting automated release builds as Travis CI "deployments." So far I know what to do with a new tag. (Still figuring out how to get the flex version number in there, but making progress.)

When you say, "build the flex release archives," are you wanting to re-build historical dist tarballs?

When you say, "build the flex release archives," are you wanting to re-build historical dist tarballs?

No, that is about running make dist -> creation of the distribution tarballs.

I'm getting the hang of scripting automated release builds as Travis CI "deployments."

Does this mean you may be able to help @westes with a PR including a script and notes how to setup that as CI that at least:

• take the take
• running make distcheck
• if it passes making a GH release out of the tag and attach the generated tarballs and attaching the first NEWS entry to it as release note
• optional, as it could be done later and manually in the meantime: "increment the recorded current and previous version numbers of flex" (whatever that means, I guess it would be a separate CI step that is triggered at the end of the first and would commit a change to the repo [or create a PR to do this] with som numbering)

?

Yep, that's the gist of it. I've worked out how to automate just about everything between the github api, Travis, automake, and some utilities. I'll probably add a maintainer script and a make target to kick it off.That's all for new releases, though.

Getting arbitrary old build systems into Travis is possible but tricky so I'd be glad not to do that.

I have Travis making a release from a tag now.

Working out how to make the gpg signatures. Are those made according to a specific formula? I'm guessing they are are detached signatures of the file hashes.

Also thinking about the NEWS file. Will building the update from the milestone be sufficient? I have a plan for how to do that with octokit.

You probably should not use Travis unless westes is willing to a) regularly ask Travis for more CI credits or b) pay for it.

Travis is not freely available in general anymore https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing

Additionally, even before the pricing change, there seems to be a misconfiguration of Travis in this repository. Travis did not run anymore since May 2018.

I would recommend looking into GitHub Actions instead.

Super. Thanks for the heads up. I got the builds working across their whole matrix without them every mentioning this has changed.

@westes what do you think about switching to GitHub Actions from Travis CI? Looks like it's a little more hassel to do multi-arch builds, but I think coordinating releases will be simpler.

It makes sense to switch to github actions. For now, I'd say ignore the mswindows and osx builds since they consume minutes at higher rates.

Rgr that. I'll get the fundamentals set up on linux/amd64 to start.

Okay, got the first chunk in place. @westes, requesting feedback on the NEWS file format and workflow. The NEWS file I'm generating is pretty basic. It's just issue numbers, titles, and labels (when available). That's all inserted at the top of the file, though, so it's possible to add more friendly news nearby just before triggering the automated release workflow.

The workflow is triggered when you close a milestone. The tag and release names are taken from the milestone title.
Start condition: A milestone exists with a name like "v2.6.5"
Entry: The milestone is closed.
Steps:

1. The new version number is derived from the milestone title.
2. Closed issues in the milestone are collected, formatted, and inserted into the NEWS file.
3. The version number is updated in Flex sources (TODO)
4. A new commit containing the NEWS and updated sources is created and pushed by the GitHub Actions runner.
5. The new commit is tagged with the version number by the GitHub Actions runner.
   If the above were successful
6. The new tag is checked out, built, and distchecked
7. The dist tarballs are signed (TODO)
8. The GitHub source tarballs are signed (TODO; perhaps redundant)
9. GitHub Actions creates a release based on the milestone name
10. The dist artifacts are uploaded to the new release
    End condition: A new tag refers to the master branch and a release built from that tag includes dist tarballs.

The gh-actions branch of my fork is in the end condition right now. The workflow files are in .github/workflows/milestone* if you want to take a look. I have a daily build workflow and some tests in there, too.

NB: The milestone workflow only runs on the default branch. I switch mine to gh-actions when I'm testing it.

PR is ready for comment. The 2.6.5-TEST "release" on my fork shows how it all turns out. I can kick off new demos without much trouble - as designed :)

@westes You've requested the automated adjustments via github-actions and there's a PR for that. Would you please review the PR? If the "automated" part does not fit for whatever reason we could "downgrade" the build to not take care of the releases and only run build + make distcheck, still providing automated tests and release tarballs for people to use from the CI.

Friendly ping @westes after a year.

I don't see what you want to automate any further.

1. build the flex release archives.
   => This is done by GitHub if you create a new release. This is easy.
2. generate release notes based on the NEWS file.
   => Auto-generated notes do not work. The lists are cluttered with uninteresting noise. From my experience, if you get (or you create one) a pull request for a change that should be part of the release notes, force people to add the information as part of the pull request. This requires some discipline during development, not for a release.
3. notify the flex-announce mailing list (NB it is ok if that email needs approval).
   => Is this really that much work to write a brief message including a copy of the GitHub release page?
4. increment the recorded current and previous version numbers of flex based on the release number from the release tag and what flex's version numbering is recorded as.
   => How should an automated mechanism decide whether you intend to do a major, minor, or patch-level increment? Again, I don't think this is the real trouble for a release.

The main burden I see is 2, creating the release notes. Changing your merge policy might help you for incoming requests. I offer to help to update the release notes since the last release.