> Yeah, not described enough in this thread, it is part of the motivation to > the proposal
I don’t believe it has been mentioned once in this thread. This should have been clearly stated upfront as a motivation. Thus far no positive case has been made on this topic, we have instead wasted a lot of time discussing clearly peripheral topics, demonstrating that the more obvious approach for anyone without this motivation is indeed fine. > Setting up versioning to be extensible in this manner is not endorsing such > artefacts and distributions. Yes, setting up versioning in this way with the intention of permitting comparisons between these “not Cassandra” releases and actual Cassandra releases is the same thing as endorsing this behaviour. It’s equally bad if this “internal” release is, say, used to support some cloud service that is advertised as Cassandra-compatible. Given the above, I am rescinding my support for either B or C, and now only endorse approach A. > Adding that library made things much easier to deal with, as adhering to a > spec and standard should You broke the spec as part of this work. The “NIH approach” was more standards compliant prior to this work (as it correctly sorted prior to 16649, except for SNAPSHOT releases). I think if anything the recent log4j issues have hopefully demonstrated that “NIH” is not the pejorative people think it should be. Independent of this discussion, I was disappointed to see this unnecessary Semver dependency introduced at the time that it was, creating unnecessary churn and compatibility work to no apparent advantage. From: Mick Semb Wever <m...@apache.org> Date: Wednesday, 22 December 2021 at 12:14 To: Cc: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps > > 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).
