Racket v8.6 Release Thread

Internals
21

1270 Lines of output.

The Discourse has a message body limited to 32000 char.

22

I think this is a successful build. In particular, I get identical output, and then make install works fine.

23

Thanks. I was expecting the build process to say the next step is

make install

without the "cc1: warning".

24

The warning is just a compiler warning in the usual way, but maybe zuo should provide a little more output there by default.

25

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?

2 Likes
26

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/. 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.

2 Likes
27

Well, the snapshot build did not succeed this time, but I'll get it sorted out in the next run or so.

1 Like
28

A Guix patch reviewer pointed out that the v8.6 tag at GitHub - racket/racket: The Racket repository seems to have been changed last week to point to repair SRC_CATALOG · racket/racket@3c5e377 · GitHub instead of Update version number for the v8.6 release · racket/racket@90d2dac · GitHub.

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/ 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 for an issue with 7.9, though.)

The "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, 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, 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.
5 Likes
29

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?

30

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.

31

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.

3 Likes
32

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.

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.

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

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:
  10. When the documentation is ready, announce the release.
1 Like
33

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?

1 Like
34

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!).

35

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 :slight_smile: ).

36

Sorry to be slow, can you clarify what thing it is you're referring to that happened to you?

37

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.

1 Like
38

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.

39

I've pushed a change to avoid warnings avoid the implementation of get_self_path.