What about splitting the difference: cassandra-5.1-backport? > Our codebase, both runtime and test code, is picky about versioning labels, > particularly ordering (which is important for upgrade tests). This comes up consistently when we talk about how we version and cut releases. Do you think there'd be value in having a separate conversation about what technical limitations we have around this right now, the level of effort to make it more flexible, and the benefits we might gain from that? (emphasis on separate conversation; don't want to derail this thread. We can take it to dev slack tomorrow. :))
On Sun, Oct 12, 2025, at 5:46 AM, Mick wrote: > > > > On 11 Oct 2025, at 19:00, Dinesh Joshi <[email protected]> wrote: > > > > On Sat, Oct 11, 2025 at 4:48 AM Josh McKenzie <[email protected]> wrote: > > I'll take a crack at those questions Dinesh: > > > >> 1. What branch would be designated as a backports branch? > > A new branch ( cassandra-5.1 ) should be created. While reusing > > cassandra-5.0 reduces overhead, changing the identity of a GA release > > mid-lifecycle risks breaking user trust (Isaac's point holds as > > foundational to me). We have no way of knowing how many operators rely on > > 5.0’s stability contract. > > > > I have a personal preference for cassandra-5.0-backports instead of > > cassandra-5.1. The naming is clear, unambiguous and communicates the > > _intent_ without having to look up documentation. > > > >> 3. What would releases look like including release cadence? > > "5.1.0-beta", "5.1.0-backport", "5.1.0-community"; some flag to denote "not > > regular GA". > > Cadence: No fixed schedule (same as current GA). Reactive to feature merge > > or volume of smaller improvements, critical bugfixes, etc. > > > > My preference is to have `cassandra-5.0-stable` and > > `cassandra-5.0-backports` artifact names. > > > What would these releases be named then ? > > Our codebase, both runtime and test code, is picky about versioning labels, > particularly ordering (which is important for upgrade tests). > > For the sake of simplicity and ease on that reason I'd rather go with the > cassandra-5.1 branch, and have any releases always marked as beta, e.g. > 5.1.0-beta1, 5.1.0-beta2, 5.1.0-beta3, 5.1.0-beta4, 5.1.0-beta5, etc. While > cassandra-5.1 and 5.1.0-betaX is not as intuitive to the purpose of a > dedicated back-port branch, I don't believe it's going to be not obvious to > anyone for very long and isn't one of the bigger challenges is organising > this pilot to be smooth. This approach is also taking advantage of an > operator's general expectations on versioning numbering (without knowing the > C* specifics). And if later on we decide we would like the back-port > releases to come out of beta, it's then easier (IMHO) to do.
