[Maintenance] Release Process, Container Updates

EasyCrypt now aims to release every 6 weeks, although we may skip some releases due to holidays. (Rather than delaying them.) This page documents the release process so the responsibility for issuing releases can be distributed among maintainers rather than being centralised.

Creating a Release

The "correct" release process is to:

1. create an annotated tag, then
2. create a release from it using GitHub's release UI, then
3. move the release branch forward to point to the newest release, then
4. consider bumping prover versions for provers present in the build-box immediately after release (letting the release settle first), to force progress on maintained proofs.

Creating an annotated tag

Making sure you are on main, and up to date with the GitHub main, run:

git tag -a ryyyy.mm -m "Release yyyy.mm"

then git push origin refs/tags/ryyyy.mm (assuming the GitHub remote is origin).

Creating the release

Go here, and:

1. select the just created tag;
2. select main as target;
3. Fill in "Release yyyy.mm" as "Release title"
4. Click "Generate release notes"
5. Make sure that "Set as the latest release" is ticked
6. Click "Publish release"
7. Bask

Since you messed it up, here is how you fix it

Most likely, you messed it up and are prevented from basking by the fact that you did not create the tag as an annotated tag before publishing a release from it, and asked GitHub to create a tag instead. To fix it, first make sure that git push -f will not do anything other than overwrite the tag (make a fresh clone of the repo if necessary):

1. git pull ryyyy.mm
2. git tag -f -a ryyyy.mm -m "Release yyyy.mm"
3. git push -f --tags
4. Bask for real

Updating the release branch

The following should do the trick, since we keep our history linear-ish.

git checkout release
git rebase ryyyy.mm
git push

Until further notice, it may be a good idea to also update the latest branch in the same way, while the deprecation percolates through user scripts.