# Racket v8.6 Release Thread **URL:** \ **Category:** Internals\ **Tags:** release-management\ **Created:** [June 22, 2022, 4:42pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091 "2022-06-22T16:42:34Z")\ **Posts on this page:** 1\ **Showing post:** 32
**Author:** ![LiberalArtist](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/liberalartist/32/151_2.png) [@LiberalArtist](https://racket.discourse.group/u/LiberalArtist)\ **Post date:** [August 24, 2022, 1:56am UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/32 "2022-08-24T01:56:44Z")
> [@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](https://www.softwareheritage.org) 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](https://github.com/racket/racket/wiki/Release-process). > [@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](https://github.com/racket/racket/commit/424d167500a9c5cb83e3f23217028954f47a69b7) 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](https://github.com/racket/racket/commit/6ef43da80cc2b84c05f7409646745d971aa8c379) 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](https://github.com/racket/racket/commit/90d2dac7976b6ac0369c267f0adec3f37bd98460) 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/](https://download.racket-lang.org/releases/), but _don't_ have it appear on [https://download.racket-lang.org](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](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. --- _[View the full topic](https://racket.discourse.group/t/racket-v8-6-release-thread/1091)._