Racket v8.6 Release Thread

[LiberalArtist]

@samth

For 8.6, people seem to want the tag not to change so deleting it sounds like it would not be the right choice.

Yes, at this point I think the right thing to do is to leave the v8.6 tag as it stands now. Making any other change seems at least as likely to break things as to fix them.

@jbclements

Historically, the github tags have not actually been a principal component of the release.

At least for Guix, it is extremely useful that all of the Git repositories involved in the release process have a v8.6 tag. We build all of the packages in main-distribution from Git sources (and I'm working to make Racket packages in general usable as Guix packages, as Guix can do for other languages), and building from Git also works especially well for e.g. automatically sending intake requests to Software Heritage for long-term reproducibility. In particular, Guix has tooling that understands vX.Y.Z and other common formats for Git release tags.

@mflatt

Now that we all know the version tag on the main repo is useful and relied on for packaging, I agree that we should have either left the v8.6 tag as broken (probably the right option) or been a lot noisier about the change (but the change here probably doesn't meet that bar). I also agree that a policy should be written into the release process at Release process · racket/racket Wiki · GitHub.

@samth

In general it seems like we should consider figuring out how to make point releases easier to make, since downstream consumers are unhappy when we change things after the release.

This sounds good to me (which is easy for me to say when I'm not responsible for the Racket release process).

@jbclements

One challenge in testing this manual makefile update are that the catalog itself must be available in order to test it, which is why this update occurs after testing is complete. One solution would be to use two tags for each release, to allow testing before the application of the final tag.

With the caveat that I don't know how this would work for other aspects of the release process, here's an idea that would make sense to me from a Git perspective, partially inspired by the sort of "soft launch" we tried this release cycle. It also tries to address a much less significant quirk I noticed, which is that the head of the stable branch tends to point to a merge commit like Merge branch 'stable' into release · racket/racket@424d167 · GitHub rather than the commit pointed to by the release tag.

1. When starting a new release branch, either just before or just after the commit like Alpha version number for the v8.6 release · racket/racket@6ef43da · GitHub setting the alpha version number, use git merge with the ours strategy so that the new head of the release branch is also a descendant of the tag from the previous release/the head of the stable branch.
2. Test, cherry-pick, and build release candidates as usual.
3. When testing is done, make a commit like Update version number for the v8.6 release · racket/racket@90d2dac · GitHub setting the release version, but don't tag it yet.
4. Build the release.
5. Upload the release under https://download.racket-lang.org/releases/, but don't have it appear on https://download.racket-lang.org yet.
6. Test that the catalogs configuration is working properly. Fix things if needed.
7. Merge the release branch into the stable branch with --ff-only.
8. Tag the release commit and the corresponding commits in the other repositories.
9. Start rebuilding the documentation. Alert distribution packagers. Possibly update https://download.racket-lang.org now, but:

   @LiberalArtist

   i think the point about the currently confusing state of the download page is good one, though. If we do this for 8.7, maybe we can add a message or something to clarify.

10. When the documentation is ready, announce the release.