> > Do you intend to use this capability, and if so could you point out where you > highlighted this motivation previously? >
Yeah, not described enough in this thread, it is part of the motivation to the proposal, and was discussed in the slack thread: https://the-asf.slack.com/archives/CK23JSY2K/p1638975919339400?thread_ts=1638950961.325900&cid=CK23JSY2K > > 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. > They wouldn't be. > > 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. > Setting up versioning to be extensible in this manner is not endorsing such artefacts and distributions. I think of it as similar to how open-sourcing the code in the first place isn't an endorsement of those that extend it. We have rules in place to avoid abuse and confusion around identities. Let's not conflate that with appreciating the ecosystem we have and the benefits of extending interoperability. > > Such software should have its own versioning that is distinct from Apache > Cassandra. > Versioning does not need to be distinct for the offering to be distinct. The versioning is entirely up to them, but sharing the same versioning comes with benefits, as mentioned above. The offering does not need to be something public either, it could be related to internal deployments. > > > > (A) does not work with the codebase as it is today. It requires additional > > work. > > 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. > Being one of those that dealt with the upgrade bugs and added in the SemVer library, I can say it is a decent amount of work (and testing) to revert and redo, and that the upgrade tests have a different need to CassandraVersion. Adding that library made things much easier to deal with, as adhering to a spec and standard should. It feels like reverting that work would be going down a NIH path (and we would have be copy the CassandraVersion class rather than being able to re-use it) for the sake of wanting to lexically instead of naturally order pre-release fields: which the spec folk see as a mistake and oversight (and have recommended users to stick with lowercase for general system compatibility). If folk really wanted A1 then I'd be pushing to A2 for this reason (and then to the limitations of A2 as described above).
