> You were part of that slack thread, so it was a bad presumption on my behalf.
I am flattered, but I’m sure your intention was in fact to involve everyone in this discussion. As it happens, I commented only on the end of that lengthy thread and did not participate in the section you linked, so was unaware of it – as I’m sure were most folk here. > 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 Actually my complaint was more general, but I was letting another pet peeve of mine leak into this discussion. We should have a separate discussion around dependency policy in the new year. I think new dependencies should not be included without discussion on list, as they introduce significant new code to the project that is rarely audited even cursorily either on inclusion to the project or update. For such a trivial feature as this, that was adequately implemented in the project already, I consider the inclusion of a dependency to be a mistake. As it happens, I don’t think this problem you raise is a concern, even with this recently introduced faulty implementation of Semver. A2 is zero cost to implement, but even A1 would be fine without any work. It is unlikely we would ever need to compare a -pre version to -alpha or any other pre-release version, as we are unlikely to perform upgrade tests across these versions since we will have no users deploying them. From: Mick Semb Wever <m...@apache.org> Date: Wednesday, 22 December 2021 at 16:02 To: Cc: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps > > 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…
