We're overhauling the Racket installer builds for the main download site (after the upcoming v8.17) and snapshot sites (sooner). One question is how much to keep building installers for the old BC variant of Racket. The newer CS variant has been the default since v8.0 (February 2021), and the intent has always been that BC would eventually become unsupported.
Does anyone need the BC installers, either in release form or snapshot form? Or can we just stop building them?
Currently, both CS and BC variants of Racket are available for most platforms. At the release download site, you have to click "More Installers and Checksums" to find BC installers, except that BC is the default installer for 32-bit x86/Intel on Windows and Mac OS.
BC will still build for the foreseeable future, and we would probably set up a periodic build of BC installers as a test. But BC builds would not be available for, say, CI tests that use a release or snapshot installation.
This change would not mean that fewer platforms are supported for Racket. For example, the 32-bit x86/Intel on Windows and Mac OS will switch to CS, but maybe only in Minimal Racket form. We'll likely expand the set of platforms with Minimal Racket builds, but provide full Racket builds only for the most popular platforms.
If we do drop BC builds, then it would make sense to number the first CS-only Racket release as version v9.0.
3 Likes
Would such a change imply a bump in version to Racket 9.0?
(I don't use Racket BC)
Can you track download stats?
Hi! v8.14, v8.15, v8.16, only [BC] versions are pre-packaged in the Termux Android app repository. At least for aarch64. Looks like they compile from source themselves. But why BC - I don't know. So subway Racket is only BC now 
FWIW - the link to Racket in Termux.
I don't have a strong view (yet, at least).
One data point is that it looks like the soon-to-be-released Debian 13 “Trixie” will be using Racket BC 8.16 on the armel architecture, which is what Debian calls 32-bit ARM without hardware floating point support. Per the changelog, the issue was that the CS build (as of 8.12) used too much memory and IIRC failed. I remember reading more about this, but I don't remember where: @bremner doubtless does.
On the other hand, apparently, while Trixie will keep armel in the Debian archive, the Debian installer is no longer being built for armel. And it is surely evidence that this is, at least, a close call, that armel is the only Debian architecture still using BC (thanks to @bremner).
Then again, the fact that BC built successfully in at least this one context in which CS hasn't does make me wonder if there are other environments where CS, at least via pbarch backends, may not yet be a strict improvement over BC.
A clarification: The original question was about the end of BC downloads (from download.racket-lang.org), not the end of BC. As noted, BC will still build for the foreseeable future, so anyone who packages that from source is unaffected by the potential change.
My last line probably muddied the question by characterizing the change as a "CS-only release". I should have written something more precise to mean that the compiled forms available from download.racket-lang.org would be only CS.
Removing BC from download.racket-lang.org is intended to be a step to further deemphasize BC, so it does connect to the general question of BC support. But the intent is not to stop supporting BC right now.
Yes, that was the intent of the last line.
BC downloads have been in the noise compared to robot traffic for a long time, so it's difficult for me to extract a relevant signal from logs.