And per Mick’s comment, we will want to try out what ever special version we come up with from a few drivers, and in a rolling upgrade from 3.11/4.0. From my experience in shoving funny version numbers in builds there are things you can do that will make version parsing code barf and crash stuff.
> On Dec 16, 2021, at 10:29 AM, Jeremiah D Jordan <jeremiah.jor...@gmail.com> > wrote: > > If we want to have “called out development snapshots” then I think we need > some way to distinguish build from those commits the from ongoing work in the > version number that is in the build file. I do not think the “development > snapshots” being 4.1.0-SNAPSHOT and current trunk also being 4.1.0-SNAPSHOT > achieves that goal. > > How we accomplish that, I don’t have any preference. Bumping the version > number such that trunk becomes 4.2.0-SNAPSHOT is a pretty simple way to > accomplish it. > > Another option would be to push and tag a commit outside of the trunk branch > that has the version as 4.1.0-pre1 or something. From my look at the > CassandraVersion code something after SNAPSHOT will not parse correctly, > -SNAPSHOT needs to be the last thing. So 4.1.0-pre1-SNAPSHOT is valid, > 4.1.0-SNAPSHOT-pre1 is not. > > -Jeremiah > >> On Dec 16, 2021, at 9:33 AM, bened...@apache.org wrote: >> >> I don’t really see the advantage to this over 4.1.0-SNAPSHOT1 >> >> From: Mick Semb Wever <m...@apache.org> >> Date: Thursday, 16 December 2021 at 15:04 >> To: dev@cassandra.apache.org <dev@cassandra.apache.org> >> Subject: [DISCUSS] Periodic snapshot publishing with minor version bumps >> Back in January¹ we agreed to do periodic snapshot publishing, as we >> move to yearly major+minor releases. But (it's come to light²) it >> wasn't clear how we would do that. >> >> ¹) https://lists.apache.org/thread/vzx10600o23mrp9t2k55gofmsxwtng8v >> ²) https://the-asf.slack.com/archives/CK23JSY2K/p1638950961325900 >> >> >> The following is a proposal on doing such snapshot publishing by >> bumping the minor version number. >> >> The idea is to every ~quarter in trunk bump the minor version in >> build.xml. No release or branch would be cut. But the last SHA on the >> previous snapshot version can be git tagged. It does not need to >> happen every quarter, we can make that call as we go depending on how >> much has landed in trunk. >> >> The idea of this approach is that it provides a structured way to >> reference these periodic published snapshots. That is, the semantic >> versioning that our own releases abide by extends to these periodic >> snapshots. This can be helpful as the codebase (and drivers) does not >> like funky versions (like putting in pre-release or vendor labels), as >> we want to be inclusive to the ecosystem. >> >> A negative reaction of this approach is that our released versions >> will jump minor versions. For example, next year's release could be >> 4.3.0 and users might ask what happened to 4.1 and 4.2. This should >> only be a cosmetic concern, and general feedback seems to be that >> users don't care so long as version numbers are going up, and that we >> use semantic versioning so that major version increments mean >> something (we would never jump a major version). >> >> A valid question is how would this impact our supported upgrade paths. >> Per semantic versioning any 4.x to 4.y (where y > x) is always safe, >> and any major upgrade like 4.z to 5.x is safe (where z is the last >> 4.minor). Nonetheless we should document this to make it clear and >> explicit how it works (and that we are adhering to semver). >> https://semver.org/ >> >> What are people's thoughts on this? >> Are there objections to bumping trunk so that base.version=4.2 ? (We >> can try this trunk and re-evaluate after our next annual release.) >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
