Just to be very clear. I think that bumping the semantic version number because some arbitrary time constraint has passed is a bad idea. Version numbers should be bumped when dictated by the change to the code. It makes sense that if you have released 3.2.0 then the next nightly snapshot would be 3.3.0-SNAPSHOT (as the assumption here is that you are adding functionality as we move forward). The Patch level changes should be reserved for cases where we have to go back and fix something (Heartbleed, log4j issues come to mind).
nightly builds, quarterly snapshots, anything that is not a "release" can be released at any time but should be listed as <semantic_version>-<some suffix to denote what this is>. For example 3.3.0-Q1_2022. If desired tags can be placed in git to show when those were built. These are not "release" builds. A "release" build has full testing (regression, integration, etc.), documentation checks, packaging verification, etc. No release build has anything after the semantic version. I am not that familiar with how C* has been built in the past, but if each component has its own cadence then it might make sense for each component to have its own semantic version and component release. C* release then assembles the component versions necessary and correct for the release and builds its own release with its own semantic version number. The C* release would include a list of all the component versions that were used to build the package. In this case C* views each of the components as a separate project. The idea of bumping version numbers when there is no change to the underlying code goes against the semantic versioning concept. If there is no change to the code, then there should be no change to the version. That is my 2cents (now probably 5cents) worth. Claude On Fri, 31 Dec 2021 at 08:42, Claude Warren <claude.war...@instaclustr.com> wrote: > I am late to this party but wanted to add my 2-cents. > > I do not think that the minor revisions should be used to denote snapshot, > nightly build, or any other not-fully-supported code. My reasoning is that > semantic versioning defines under which conditions the version numbers are > to change. By looking at the version I can tell if it is a bug fix or > added functionality change. My experience, both with the Apache Jena > project, and at my places of employment, is that version numbers are best > left to identify what type of change is being offered. If the package is > not a release package then it should have some sort of version extension > (e.g. -SNAPSHOT, -RC1, etc). > > In the Jena project we do not release on a clock/calendar based schedule, > rather we decide that there is enough change in the product and that it is > sufficiently tested and then we go through a release. Before that it is > always just a SNAPSHOT. > > My take on all of this is that anything versioned x.y.x should be a fully > supported release. That means fully tested, fully documented, packaging > tested, the works. Fully meet the expectations of an Apache package. Any > version that has other bits at the end should be noted in the site > documentation as being not fully baked and perhaps an explanation of how > poorly baked they are. > > Keep in mind that making a release is a time consuming process. More > releases mean more time spent preparing and supporting the releases, more > time answering questions about differences between releases. > > So, for me, this boils down to two things: > > 1. Keep the version numbers clean and use suffixes to identify > non-standard releases and level set expectations for those releases. > 2. Keep it simple. Don't plan lots of releases unless there are lots > of people that want to do the packaging and support. Remember that > automation never made anything easier, it just moved the pain point > somewhere else. > > Claude > > On Thu, 23 Dec 2021 at 00:28, bened...@apache.org <bened...@apache.org> > wrote: > >> > 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… >> >
