> > 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. >
Apologies for not previously stating and explaining this additional motivation in this thread. You were part of that slack thread, so it was a bad presumption on my behalf. > > 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. We have many versionings at play, and they are used between codebases in our ecosystem. Forcing people to use their own versioning may well require them to then have to adapt other codebases/components unnecessarily. In turn we might lose some of the benefits from their testing efforts. Here I disagree with you, let's leave it at that. > > 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). > Please, we are chasing each other's tails here. I understand that you to follow the SemVer spec strictly wrt to pre-release fields being case-sensitively lexically ordered, despite the author's of the spec stating that this was an oversight, recommending the field be kept lowercase, and suggesting it might become case-insensitively naturally ordered in version 3 of the spec, while implementations of the spec are also taking different approaches because of the ambiguity caused here. But, I wish not to be dragged into having to defend my contributions made when we were fixing tests and trying to get 4.0.0 over the line. Especially when those contributions moved things forward on a pure bug count, and the complaint raised by you is that it doesn't case-sensitively lexically order and undermines the proposal choice you want to see go forward. I hear your opinion, stand by your right to express and vote by it, but do not wish to engage in this way. > > I think if anything the recent log4j issues have hopefully demonstrated that > “NIH” is not the pejorative people think it should be. > I certainly do not stand firm to NIH or DRY - it's only food-for-thought in any code discussion, nothing more. The comparison to log4j isn't fair, it's a small library of five small classes that does exactly what we needed. There's no risk here, and I'd not be interested in rewriting every small and safe library we use. And I agree with the sentiment that we need to be vigilant about the libraries we introduce into the project. But again, I really wish not to go around in circles. For now I hope we can engage on more "open" fronts, so we can continue to explore and understand…
