Some thoughts about alphas/betas/RCs

after the current versioning mess I was thinking a bit about having some
release cycle spec with Alphas/Betas/RCs, instead of naming everything "RC".

What do you think of
- having an "Alpha" release as soon as there is any considerable
feature change or addition compared to the last stable version, to get
early feedback on the changes without anyone expecting that this version
is stable at all (or the discussed feature even making it into release
in that form). This would happen much earlier than the current first RC
release. Probably more alpha releases as changes/additions change
considerably.

- having a "Beta" release, where things are considered more mature and
with the expectation that the library additions/changes at this state
could be the way they end up in a final release. More Beta releases as
things fall into place. This would start a few weeks before the current
first RC release. More Beta releases as design nears finalization. This
would mean some of the first RCs currently would be called Beta.

- having "RC" releases, which could end up like that (with renaming)
as a final release if no bug is found anymore. If some bugs are found, a
new RC is issued. (OR: Having a short, well-defined list of bugs at the
beginning of the RC phase and having a "rampdown" saying "as soon as all
of them are fixed, we reached final".) This would be the same as
currently done.

Just some thoughts ... no idea if JIRA makes it easier to rapidly issue
more "builds" or if there is too much bureaucratic overhead for that.

after the current versioning mess I was thinking a bit about having some release cycle spec with Alphas/Betas/RCs, instead of naming everything "RC".

What do you think of
- having an "Alpha" release as soon as there is any considerable feature change or addition compared to the last stable version, to get early feedback on the changes without anyone expecting that this version is stable at all (or the discussed feature even making it into release in that form). This would happen much earlier than the current first RC release. Probably more alpha releases as changes/additions change considerably.

-1, nightly builds already serve this role adequately. From following nightly builds, I haven't noticed that there are lots of times where an alpha makes much sense; progress tends to be made on multiple fronts.

- having a "Beta" release, where things are considered more mature and with the expectation that the library additions/changes at this state could be the way they end up in a final release. More Beta releases as things fall into place. This would start a few weeks before the current first RC release. More Beta releases as design nears finalization. This would mean some of the first RCs currently would be called Beta.

+10, RC1 really should have been a beta this time. Any time major new features are introduced (including major changes to the library) there should be at least one beta before any RCs. I was, for instance, very surprised to see the state of the parallel collections library in the supposed release candidate for 2.9--but if it had been marked a beta, my initial instinct would have been to think, "Oh, well, beta is a good time to iron out backwards compatability" rather than a heart-sinking feeling of, "I can't believe they thought this was ready to release". My instinctive reaction was quickly replaced with the realization that labels are just labels, and an error in labeling is no big deal, but still, it's good to align one's labels with people's expectation of what the labels mean.

-100, using extra digits as a flag is clunky and scales poorly if things don't go as you anticipate (what if serious bugs continue to be found and there are 11 betas, for example?) Let's not start encoding flags and strings into our version numbers, please.

--Rex

P.S. We should make sure everyone uses BigInt version numbers--maybe we can encode the entire release there! :)