Racket v8.7 Release Thread

[LiberalArtist]

@elibarzilay

• Re your suggestion of not creating the tag until some testing, the original motivation for creating the tag as soon as the version is bumped (for releases) is to avoid a situation where there are two builds with the same version number that are not the same code, so there's no chance of confusion. There was even at some point a bit in the release where I faked the new version number so I can update things like screenshots (and some Shriram-related things too?). Probably mostly moot now.

This makes sense. (@jbclements also pointed me to some complications off-list.) If we try to revisit this idea next release, one thing I noticed is that https://github.com/racket/release-catalog/blob/master/scripts/add-tags.rkt currently creates tags using the GitHub API: maybe creating tags locally could keep some benefits but be more flexible? But I also think it might be a better use of effort to just do as @samth suggested elsewhere:

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

@elibarzilay

• The reason for the "alpha" releases were due to some big-ish changes that streched over a longer period (e.g., 369.100). All of that is before "rc" was as common as it is now. (If that code is doing the same thing it did then it's probably crying out for attention.)
• I have a vague memory of making up the format of version.txt instead of the older code which was some other filename. To change the format you can play the same game by making the code use some new version.rktd file with whatever's needed, and leave version.txt to point at the new version so there's no problem with older versions.

This is useful context, thanks! The fact that "alpha" releases were a different sort of thing than either "pre-release"/"release candidate" or "snapshot" builds currently (both of which are relevant for a fairly short time) reinforces my thinking that we should leave this alone and just document the current state of affairs. If someday someone wants to add new version-related functionality that would be useful in the current context (e.g. warning you if you have a stale release candidate), as you say, they can add a new file or something: that seems better than overloading the meaning of "alpha" anyway.

@jbclements

Philip, I'm on board with the suggestion of not doing much other than documenting the current situation. Your language, "I'd be inclined," suggests that you might not be averse to coming up with this language?

Sure, I'll try to make a PR soon.

@elibarzilay

• By some cosmic coincidence, I went over this branching approach in the last few weeks (due to $work), and implemented roughly the same strategy, automated via a github action. One thing that I've noticed (~two days ago) is that due to merges going only from master to release to stable but not the other way, GH shows stable as being way ahead of master. I figured that an improvement there would be exactly the kind of -s ours fake merge to avoid that confusion.

Interesting! To be concrete, are you suggesting that, after tagging the release and updating stable, we should git checkout master && git merge -s ours stable? That seems like a nice enhancement! In addition to showing which branch is "ahead", it would also record where we were in the history of master when we released a given version.