> > general feedback seems to be that users don't care so long as version > numbers are going up
Curious to hear more about this. It doesn't match my intuition or experience running systems but I'm also n=1 and there's a lot of opinions in the world. Leap-frogged by Benedict's response here, but I'm in favor of something like: 4.1.0-SNAPSHOT-22Q1 4.1.0-SNAPSHOT-22Q2 ... Keeps lexicographical comparison but also embeds the intent of the release and when it hit all in one bundle. And doesn't blow up our minor #'s and lead to confusion. ~Josh On Thu, Dec 16, 2021 at 10:03 AM Mick Semb Wever <m...@apache.org> wrote: > 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 > >
