(Paulo)
The proposal is not using minor versions to represent snapshots (see the
summary below).
> I think we can overcome any technical limitations
We can, but this is about more than just us (see below).
(Benedict)
> What’s so different about using 4.1.0 that permits avoiding extra work?
> …
> 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?
By "proposals that work" I mean those that will work today with the
codebase as it is. Your proposal is possible. Nevertheless, it requires
fixes (more than just CassandraVersion), and more importantly requires
others in the ecosystem to adapt.
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.
This (my) proposal is intended to be very simple.
All we are talking about is the following change
a) tag last 4.1 sha
git tag cassandra-4.1-dev
b) and patch build.xml:
- <property name="base.version" value="4.1"/>
+ <property name="base.version" value="4.2"/>
That's it. No release exists. No announcement made.
We can do a deploy of the last 4.1 snapshots to
https://repository.apache.org/content/repositories/snapshots/
And we can put dev packages of the last 4.1 snapshot onto
https://dist.apache.org/repos/dist/dev/cassandra/ (if we want to*).
This enables our ecosystem and users to start dev testing trunk at a fixed
point. Without anyone ever saying that these have gone from
snapshot->alpha just the same as the snapshot artefacts found in nightlies,
e.g.
https://nightlies.apache.org/cassandra/trunk/Cassandra-trunk-artifacts/977/Cassandra-trunk-artifacts/jdk=jdk_1.8_latest,label=cassandra/build/
