# 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:** 19\ **Page:** 2
**Author:** ![Roc](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/roc/32/665_2.png) [@Roc](https://racket.discourse.group/u/Roc)\ **Post date:** [August 11, 2022, 4:19pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/21 "2022-08-11T16:19:11Z")
[1270](https://pastebin.com/sVKrb2jH) Lines of output. The Discourse has a message body limited to 32000 char. ---
**Author:** ![samth](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/samth/32/3_2.png) [@samth](https://racket.discourse.group/u/samth)\ **Post date:** [August 11, 2022, 4:28pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/22 "2022-08-11T16:28:46Z")
I think this is a successful build. In particular, I get identical output, and then `make install` works fine. ---
**Author:** ![Roc](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/roc/32/665_2.png) [@Roc](https://racket.discourse.group/u/Roc)\ **Post date:** [August 11, 2022, 4:40pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/23 "2022-08-11T16:40:00Z")
Thanks. I was expecting the build process to say the next step is > make install without the "cc1: warning". ---
**Author:** ![samth](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/samth/32/3_2.png) [@samth](https://racket.discourse.group/u/samth)\ **Post date:** [August 11, 2022, 4:42pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/24 "2022-08-11T16:42:05Z")
The warning is just a compiler warning in the usual way, but maybe `zuo` should provide a little more output there by default. ---
**Author:** ![duncanmak](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/duncanmak/32/667_2.png) [@duncanmak](https://racket.discourse.group/u/duncanmak)\ **Post date:** [August 11, 2022, 8:16pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/25 "2022-08-11T20:16:37Z")
In the 8.6 release notes, there's a mention of running on Windows on ARM64. Will there be native binaries for the 8.6 release posted to the Downloads page? ---
**Author:** ![mflatt](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/mflatt/32/6_2.png) [@mflatt](https://racket.discourse.group/u/mflatt)\ **Post date:** [August 12, 2022, 9:23am UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/26 "2022-08-12T09:23:27Z")
Even though Racket now builds for Arm64 Windows, there are not binaries on the main download page. I've enabled Arm64 Windows builds at the Utah snapshot, so a build should be available in a few hours at [https://snapshot.racket-lang.org/](https://snapshot.racket-lang.org/). And since there seems to be demand (someone also asked on Discord), I hope we can get Windows Arm64 binaries into the release build for v8.7. ---
**Author:** ![mflatt](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/mflatt/32/6_2.png) [@mflatt](https://racket.discourse.group/u/mflatt)\ **Post date:** [August 12, 2022, 2:15pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/27 "2022-08-12T14:15:20Z")
Well, the snapshot build did not succeed this time, but I'll get it sorted out in the next run or so. ---
**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 22, 2022, 6:39pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/28 "2022-08-22T18:39:31Z")
A Guix patch reviewer pointed out that the `v8.6` tag at [GitHub - racket/racket: The Racket repository](https://github.com/racket/racket) seems to have been changed last week to point to [repair SRC\_CATALOG · racket/racket@3c5e377 · GitHub](https://github.com/racket/racket/commit/3c5e37774fa7acd04fb648187e080a3c62a0d4ea) instead of [Update version number for the v8.6 release · racket/racket@90d2dac · GitHub](https://github.com/racket/racket/commit/90d2dac7976b6ac0369c267f0adec3f37bd98460). Mutating Git tags causes problems for distribution package managers that validate the source's checksum after downloading it. (Changing [https://download.racket-lang.org/releases/8.6/](https://download.racket-lang.org/releases/8.6/) causes similar problems for distributions that download things there, but the release page still seems to be based on the older commit. See [Source codes file from official site's checksum changed · Issue #3639 · racket/racket · GitHub](https://github.com/racket/racket/issues/3639) for an issue with 7.9, though.) The ["On Re-tagging"](https://git-scm.com/docs/git-tag#_on_re_tagging) section of the Git manual strongly urges against mutating tags that have been published and says: > If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying: > > [...] > > Does this seem a bit complicated? It **should** be. There is no way that it would be correct to just "fix" it automatically. People need to know that their tags might have been changed. The only case I know of a well-justified destructive tag change is [A note on the 5.12-rc1 tag - Linus Torvalds](https://lore.kernel.org/all/CAHk-=wjnzdLSP3oDxhf9eMTYo7GF-QjaNLBUH1Zk3c4A7X75YA@mail.gmail.com/), where the tag in question was renamed to `v5.12-rc1-dontuse` because "you can end up with a filesystem that is essentially overwritten by random swap data". The severity of the bug is relevant because trying to fetch a tag that doesn't exist or points to an unexpected object id in many cases leads to a hard failure: that's good if you're trying to stop people from corrupting their filesystems, but not in many other cases. I have two suggestions for future releases: 1. I think we should decide how Racket will handle these rare post-release issues and add that to the release process documentation. My basic inclination would be to make a 8.6.1 release, but that is at least somewhat more complicated for Racket than for a stand-alone application. Hopefully the answer will be one that minimizes problems for packagers, but, in any case, if the approach is documented, packagers can at least adapt accordingly. (For example, Guix can use object ids directly instead of tags for packages that have a pattern of causing tag problems, though this makes some tooling slightly less useful.) 2. When I looked at [Source codes file from official site's checksum changed · Issue #3639 · racket/racket · GitHub](https://github.com/racket/racket/issues/3639), it struck me that the problems with both 8.6 and 7.9 were with the `catalogs` configuration. Maybe we can figure out how to catch such problems during testing? Similarly, I haven't found it just now, but I think @mflatt raised the possibility of changing how catalog urls are built so that the lack of a trailing `/` wouldn't break things. ---
**Author:** ![jbclements](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jbclements/32/11_2.png) [@jbclements](https://racket.discourse.group/u/jbclements)\ **Post date:** [August 23, 2022, 4:42am UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/29 "2022-08-23T04:42:11Z")
Mea culpa, both the problem (the removal of the trailing slash) and the "solution" (that is, the re-tagging) are my responsibility. 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. Historically, the github tags have not actually been a principal component of the release. Perhaps in this case it would be simpler just to delete the v8.6 github tag altogether. Thoughts? ---
**Author:** ![samth](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/samth/32/3_2.png) [@samth](https://racket.discourse.group/u/samth)\ **Post date:** [August 23, 2022, 1:34pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/30 "2022-08-23T13:34:04Z")
For 8.6, people seem to want the tag not to change so deleting it sounds like it would not be the right choice. 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. ---
**Author:** ![mflatt](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/mflatt/32/6_2.png) [@mflatt](https://racket.discourse.group/u/mflatt)\ **Post date:** [August 23, 2022, 11:48pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/31 "2022-08-23T23:48:55Z")
My fault, too, since I suggested the "repair". It's not always obvious in what ways the things that we publish matter. For packaging purposes, it makes sense that `v8.6` should not change. For someone trying to build from a Git checkout, though (which was the original intent of the tag), it didn't seem useful to have a broken `v8.6` whose configuration is out of sync with the distro archives. 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). ---
**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. ---
**Author:** ![hendrikboom3](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/hendrikboom3/32/2748_2.png) [@hendrikboom3](https://racket.discourse.group/u/hendrikboom3)\ **Post date:** [August 25, 2022, 10:12am UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/33 "2022-08-25T10:12:36Z")
Debian has a version numbering scheme in which the tilde (~) sorts before anything else, even end-of-string. It's useful for giving version tags to pre-release versions. So an alpha or beta version can be numbed "3.6~5", which sorts before "3.6". So the final release (after _all_ testing) can be numbered "3.6"; whereas the beta versions, which get thoroughly tested, including testing all the relevant catalogs, get numbered "3.6~1:, "3.6~2", etc. Is there any reason such a convention would not work for Racket? ---
**Author:** ![jbclements](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jbclements/32/11_2.png) [@jbclements](https://racket.discourse.group/u/jbclements)\ **Post date:** [August 30, 2022, 3:16pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/34 "2022-08-30T15:16:57Z")
This all sounds reasonable to me, and it looks like the only extra step for me is step 6, testing that the catalogs configuration is working correctly. On the other hand, I'm not confident in my ability to anticipate problems. Here's one question: the tagged git release embeds a reference to a catalog URL. Does that catalog refer to the v8.6 tag on the racket repository? If so, that could cause a chicken-and-egg problem. I'm also leery of the git change on general principles; I'm not confident in my ability to predict problems with updated git protocols (as this whole issue demonstrates!). ---
**Author:** ![hrvoje064](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/hrvoje064/32/729_2.png) [@hrvoje064](https://racket.discourse.group/u/hrvoje064)\ **Post date:** [September 12, 2022, 2:43pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/35 "2022-09-12T14:43:37Z")
Exactly the same happened to me just now. I was compiling or rpi4 on Raspberry OS 64 (Bullseye). However the build was successful. I tried both ways, standard UNIX compilation, and in-place compilation and both worked. The only difference from my previous compilation on Raspberry OS 32, was that this install on 64, does not set the path, properly, or maybe this is the OS problem (probably 🙂 ). ---
**Author:** ![jbclements](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jbclements/32/11_2.png) [@jbclements](https://racket.discourse.group/u/jbclements)\ **Post date:** [September 12, 2022, 3:42pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/36 "2022-09-12T15:42:02Z")
Sorry to be slow, can you clarify what thing it is you're referring to that happened to you? ---
**Author:** ![hrvoje064](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/hrvoje064/32/729_2.png) [@hrvoje064](https://racket.discourse.group/u/hrvoje064)\ **Post date:** [September 12, 2022, 4:46pm UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/37 "2022-09-12T16:46:24Z")
That was just a confirmation about an error (or warning) at the end of compilation on raspberry pi 4B (ARM). I got the same error as the guy who originally reported it. However, racket seems to be working okay. This is on raspberry pi OS 64, that I just upgraded. I do not think it was happening before with raspberry OS 32. ---
**Author:** ![hrvoje064](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/hrvoje064/32/729_2.png) [@hrvoje064](https://racket.discourse.group/u/hrvoje064)\ **Post date:** [September 13, 2022, 9:33am UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/38 "2022-09-13T09:33:03Z")
Just to try this (and another, long standing issue) out, I installed today Ubuntu64 on my daughter's rpi4B. The make produced the same error as mentioned above, and although racket itself works, it appears that make (or install) did not complete the job completely. Namely, the PATH was not set (I installed as always to /usr/local/racket/). OK, that's easy, I just set the PATH myself, but "files" can not find drracket at all, so I have to open racket source via the terminal. This was not happening before when I compiled 8.5 on Raspberry OS 32. ---
**Author:** ![mflatt](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/mflatt/32/6_2.png) [@mflatt](https://racket.discourse.group/u/mflatt)\ **Post date:** [September 15, 2022, 2:16am UTC](https://racket.discourse.group/t/racket-v8-6-release-thread/1091/39 "2022-09-15T02:16:19Z")
I've pushed a change to avoid warnings avoid the implementation of `get_self_path`. [Previous page](https://racket.discourse.group/t/racket-v8-6-release-thread/1091.md?page=1)