DO NOT MERGE: Have release-tagged versions use the proper catalog for their release.

[stamourv]

At least twice now, users have reported trying to build a release from source by checking out the release's tag (or downloading one of github's "release" bundles). The result is a build that has, say, a 6.12 main repo, and tries to get the latest version of packages from pkgs.r-l.org, which (usually) won't work.

A likely better solution would have to have release-tagged branches default to using the release catalog from the appropriate release. This is what the change in this commit would do.

So the idea would be to add a similar commit (with the appropriate version number) to release branches (which get turned into version tags) as the release is finalized. Such commits would never find their way to master (as they shouldn't).

If that solution has legs (and won't break anything else), I'll add it to our release scripts.

[cc: @samth, @endobson ]

[rfindler]

Not commenting on the technical specifics, but this makes a ton of sense to me, generally speaking!

[samth]

This seems like the right thing to me (this happened to @spall as well). One drawback is that this won't work during the period before that catalog is created, of course (although it ought to fall back to pkgs.racket-lang.org, right?).

[stamourv]

It should fall back to pkgs.r-l.org, yes.
But I'm thinking of switching the catalog only as the release is finalized (and the release's catalog reaches its final location). Before that, everyone should really use the pre-release builds (source tarballs if necessary), not a git checkout.

[samth]

I'm mostly thinking of various CI runs, but I think it'll probably work.

[mflatt]

This seems good to me, too.

[stamourv]

Ok, I'll update the release scripts.
Thanks!