4.1.0-pre1 sounds good to me. From: Jeremiah D Jordan <jeremiah.jor...@gmail.com> Date: Thursday, 16 December 2021 at 16:37 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps 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
