Should we consider publishing release candidates ("rc")?

General
1

(With apologies if the release-management tag is inappropriate.)

The recent thread about 8.17 package failures had me thinking about release candidates in other communities. For example, Git and Alacritty both publish -rc packages that early adopters are welcome to test and report issues with; bugs may still be fixed before the release is finalized.

Is there value to Racket—in the same spirit as being pro-active about testing packages—in publishing release candidates that mirror what will be in the final release (modulo bugfixes)?

I imagine, perhaps naïvely, that a combination of the 2 ideas might have uncovered the dc<%> breaking change and provided an opportunity to change the final release in some way that avoids the problem. (I won't pretend to guess at what that change might be; the important thing, in my mind, is that it would be a normal part of the process to fix "release bugs," even if they come from code that has mostly stabilized for folks living on the bleeding edge of Racket.)

1 Like
2

I'm not informed enough to contribute but I am interested if others have insight regarding the observation and question from @robby :

And I do think this points at a larger design point. The way classes and interfaces work is not backwards-compatibility friendly. Is there something else that would be more friendly?
Package regressions for 8.17 · Issue #5257 · racket/racket · GitHub

How do other long lived projects [1] with backwards compatibility needs address this?

Best regards,

Stephen :beetle:

  1. including projects in other languages with classes and interfaces ↩︎

3

Racket already does this, you can see the pre release versions at https://pre-release.racket-lang.org/.

1 Like
4

@benknoble , I agree that it would be nice to discover problems with the release earlier; in this case, I think the fault is primarily mine. Specifically, it's the pkg-build regressions that uncovered this, and I think it's important to be checking this source of information substantially earlier. I've adjusted the release checklist to try to push this up, to make sure that these checks happen before the beginning of manual testing.

1 Like