>The problem I have with (A2) is that third-parties, vendors, etc, can only
>clumsily extend and continue on those version numbers. 4.1.0-alpha2-myvendor-3
>is awkward.
Do you intend to use this capability, and if so could you point out where you
highlighted this motivation previously?
These snapshots are not releases for broad consumption, and definitely are not
meant to be consumed by third-parties for release as Cassandra-like software.
Third-parties releasing such software are _not offering Apache Cassandra_.
Helping these entities to release software that might be interpreted as Apache
Cassandra, and to be consistent with Apache Cassandra’s release schedule, is
almost certainly a problem with this approach, not an asset. Such software
should have its own versioning that is distinct from Apache Cassandra.
>(B) has not been suggested anywhere in the thread, so I find it odd that it
>was proposed.
Ok, I misunderstood your proposal, I had not anywhere seen you intended to
include a -SNAPSHOT suffix. C{1,2,3} can be interpreted as supporting -SNAPSHOT
rather than -pre, and I guess (B) will get very few votes, and/or can be
ignored.
> (A) does not work with the codebase as it is today. It requires additional
> work.
This is untrue. A2 requires no additional work, and A1’s only issue is that we
use a standard’s non-compliant Semver implementation that was introduced in May
for some unspecified reason. If we simply used CassandraVersion (which is
broadly equivalent, but standard’s compliant) everything would seem to be fine.
From: Mick Semb Wever <m...@apache.org>
Date: Tuesday, 21 December 2021 at 22:06
To:
Cc: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
> 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
>
(A) does not work with the codebase as it is today. It requires additional work.
(B) has not been suggested anywhere in the thread, so I find it odd
that it was proposed.
(C2) is the original proposal. (Though the build metadata suffix is
not "pre", it is either SNAPSHOT or a timestamp.)
(B3) and (C3) doesn't follow SemVer.
(C1) is interesting, I wouldn't object to it, though share similar
initial reaction to Josh.
