Repository navigation
Improve terminology ("release candidate" is not a release candidate) #429
Description
Each major release, we push out builds versioned as vN.0.0-rc.M (where N and M are integers). These builds are invariably not release candidates despite being called "release candidates" and having rc in the version name. They are invariably expected to get more commits whether or not bugs are found in them. They are beta releases, not release candidates.
Ref: https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate
I would love for us to release actual release candidates, although that kinda means we don't have a date for a final release, but rather a date for a release candidate. That would be a significant change.
But perhaps we can at least have a somewhat less significant change to improve the naming. I would propose either beta or simply numbering them as pre-release the semver way (like we already do but drop the rc., so e.g. v12.0.0-0 followed by v12.0.0-1. (Or if we like the beta label, v12.0.0-beta.0, v12.0.0-beta.1, etc.)
Activity
Trott commentedon Mar 26, 2019
Ref: nodejs/node#26930 (comment)
Trott commentedon Mar 27, 2019
Here's a suggestion: Once the semver-major cut-off date has passed, an actual release candidate is cut. If there are no showstopper bugs identified in the release candidate, that's it. It's the release. Congratulations, you finished weeks early.
Sure, there will be patches and minors that people will want in Node.js version N.0.0, but they can go in N.0.1 or N.1.0.
That might make things easier for everyone. (But, of course, there's a lot I don't know about releases--like, pretty much everything--so maybe I'm wrong and this would complicate things for reasons I'm not realizing.)
MylesBorins commentedon Mar 27, 2019
@Trott that would be a major departure from how we've handled release candidates across all release lines and I'm explicitly -1 on it. While I think moving towards doing betas and creating a distinction between betas and rc's are a good idea it requires a big change to both process and tooling (ci-release). This isn't something I think we should be looking to implement at this point, but definitely something to target for 13.x or alternatively something to experiment with after the 12.x release.
BridgeAR commentedon Mar 27, 2019
I agree with @MylesBorins that this would be difficult in the current state. If our tooling improves a lot, we could go into that direction.
I do not think that our current RC handling is too bad either, since the release is not becoming an LTS release right away and people mostly try it out, when it's final (and most companies I know mainly use LTS versions and only play around with current from time to time).
mhdawson commentedon Apr 2, 2019
I agree we should consider the suggested changes to the process for 13.x as opposed to any earlier.
BridgeAR commentedon Apr 29, 2019
Should this stay upon?
BridgeAR commentedon May 21, 2020
Closing due to the age without anyone following up on it.