Legion Release Process

by Sean Treichler, December 12, 2022

1. Ideally 3+ weeks before the end of the month, prime the CHANGES.txt file by adding a section for the new release and a few changes for your areas and/or the general areas that nobody really owns. (Bonus points: push with -o ci.skip to avoid wasting CI cycles on such a commit.)
2. Email everybody and set a target at least 1 week before the end of the month for folks to get changes listed (and any last-minute commits done).
3. During these two weeks, nag people to document changes and also watch the github mirroring for the master branch. If it's not happening regularly, the full CI runs are failing and that should be cleaned up before the release. :)
4. Once CHANGES.txt is ready and you've got a recent-ish successful mirror commit to github, create an rc branch based on that commit, and:
   1. finalize CHANGES.txt (I usually set the release date 2 days in the future to account for testing latency, but I doubt anybody cares that much)
   2. update the VERSION file for the new release name
   3. push the branch to gitlab with -o ci.skip - no need to do a short CI run
5. From the web interface, kick off a full pipeline for the newly-pushed rc branch
6. Once the full pipeline passes, do a fast-forward merge (if it's not a fast-forward, something went wrong somewhere) to stable, and again push that with -o ci.skip
7. From the web interface, kick off a full pipeline for stable, setting MIRROR_OK to 1.
8. Once that pipeline passes and the mirror happens, create the appropriately named tag and push it to both gitlab (again, -o ci.skip is your friend) and manually to github as well.
9. Press buttons on github to turn that tag into a release.
10. Send email to the legion users list.
11. Merge stable back into master and delete the rc branch.