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
