After much discussion, I see three basic categories of approach:
A) distinguish releases using unstable release suffixes only
B) distinguish releases using some version number modification
C) distinguish releases using some version number modification AND unstable
release suffixes to indicate these builds are unsupported
These can be further subdivided to:
A1. 4.1.0-PRE{1,2,3,4} -> 4.1.0-alpha1
A2. 4.1.0-alpha{1,2,3,4} -> 4.1.0-alpha5
B1. 4.1.{0,1,2,3} -> 4.1.4-alpha1
B2. 4.{1,2,3,4} -> 4.5.0-alpha1
B3. 4.{1,2,3,4} -> 5.0.0-alpha1
C1. 4.1.{0,1,2,3}-pre -> 4.1.4-alpha1
C2. 4.{1,2,3,4}.0-pre -> 4.5.0-alpha1
C3. 4.{1,2,3,4}.0-pre -> 5.0.0-alpha1
I vote, in order of preference, for A{1,2},C{1,2,3},B{1,2,3}
From: Mick Semb Wever <m...@apache.org>
Date: Tuesday, 21 December 2021 at 15:48
To:
Cc: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
> My preference is to get our versioning as standard Semantic Versioning as
> possible, to avoid any precedence that depends on finely reading through the
> spec that isn't otherwise popular. Requiring the ordering of the pre-release
> tag to be case-sensitive alphanumeric is an example of this, but only one.
I am not comfortable relying upon the pre-release tag being
case-sensitive alphanumerically ordered.
Standardising on lower-case pre-release labels and build metadata can
be beneficial, especially when
cross-platform scenarios are considered. (One of SemVer author's own words.)
One example implementation exists here (in a library that we do already use)
https://github.com/vdurmont/semver4j/blob/master/src/main/java/com/vdurmont/semver4j/Semver.java#L235
And when it comes to cognitive load, I would question the load of
knowing what the difference between PRE1 and SNAPSHOT is (when there
is none), and why we use a custom pre-release tag on builds that are
not releases.
