> "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.
