> I would like to point out that the code and tests do not support "pre" as a pre-release label. 4.1.0-pre1 would break the code.
If true this can easily be fixed, but AFAICT CassandraVersion is happy to parse this just fine so I doubt there would be many breakages. > using a pre-release version needs a label that is alphanumerically before "alpha" 4.0.0-PRE1 > not having to rollback version numbers and changelogs What is unique about this situation versus alpha, beta and rc? Because these are again much more common, so whatever we do to handle these can surely be applied here? Why can’t we leave in 4.0.0-PRE1 changelog and release notes, if this is such a big deal? What’s so different about using 4.1.0 that permits avoiding extra work? If this is truly impossible, why not use patch numbers rather than minors (with additional PRE1)? i.e. we could go 4.0.0-PRE1, 4.0.1-PRE2, 4.0.2-PRE3, 4.0.4-alpha. I don’t like this, but I dislike it a lot less than using unqualified minors. > We still have only one proposal on the table that works, as was first raised in this thread. I’m afraid I’m still flummoxed by this. Could you enumerate precisely what makes this proposal not work, as I still don’t see it? From: Mick Semb Wever <m...@apache.org> Date: Friday, 17 December 2021 at 09:18 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps > "During the lead up to 4.0.0 there was plenty of headache and fixes going > in to deal with how we parse version numbers in different places and > alpa|beta|rc etc. I would rather bump the versions during the dev cycle and > work on fixing it, than have that headache again at release time. I also > feel for third-parties that have to parse our own way of versioning." > Thank you Mick for sharing again the release management point of view. It > is always a challenge to find a release manager who will have the time to > spend on those things and often those efforts are not even really visible > so it is easy to underestimate them. (All the break&fix that goes with it) > Thanks for the summary run-through and support Ekaterina, much appreciated. I would like to point out that the code and tests do not support "pre" as a pre-release label. 4.1.0-pre1 would break the code. Furthermore, the pre-release version is alphanumerically sorted, therefore "pre" would land between the last beta and the first rc version. Such a proposal using a pre-release version needs a label that is alphanumerically before "alpha". And the code would need to be fixed to accept and sort the new label. Maybe the drivers too, Jeremiah? "For the release manager this is a simpler approach (not having to rollback > version numbers and changelogs), and for those using development published > artefacts (nightlies, staging, etc) (not having versions clobbered). > Release manager practices aside, as a user I agree with Brandon, what > matters is the version is greater and whether major/minor/patch numbers are > greater." > This is a very important point. Release management is time consuming enough > and from what I've seen there are not many people who have that time to > dedicate it. If there are suggestions for different ways to improve that > experience, please, share them. Such a change (replacing takeX with version increments when a vote fails) wasn't part of my proposal here. It was only meant as anecdotal. It is still useful to know that this situation can arise for the release manager, e.g. if the artefacts were accidentally published. After carefully reading the thread, it seems to me we need to find the > right balance between: > 1) users' understanding about versions; also usability > Please, people, share your experience and feedback, we want to hear it! > 2) no breaking changes for the ecosystem (or at least as little as > possible) > 3) efficient release management (minimal maintenance). > We still have only one proposal on the table that works, as was first raised in this thread. The only valid objection raised so far is cosmetic, touching on (1). I want to emphasise that it being cosmetic doesn't make it trivial or to be ignored: the image of the project belongs to the community; it's an acceptable objection. But I hope that objections can be followed up with working proposals. Reiterating, the cosmetic change would be that our next yearly release be 4.1 or 4.2 or 5.0 or 5.1 or 5.2 (as we would not be doing more than two periodic snapshots before next May). Another concern raised was the released artefacts can have a quality pre-release label attached (alpha|beta|rc) while other unreleased artefacts would have no such pre-release label, indicating that the latter has a stability the former does not. This isn't true: these unreleased periodic artefacts are only available via dev/snapshot channels. They would be the same as builds off trunk are today, which currently is "4.1" without any such pre-release label. There's no rush on this thread, happy to let it continue through to January. Thanks for speaking up Ekaterina, I hope others do too.
