+1 from me too. Regarding Benedict's point, backwards incompatibility should be minimal; we modified snitch behaviour slightly, so that local snitch config only relates to the local node, all peer info is fetched from cluster metadata. There is also a minor change to the way failed bootstraps are handled, as with TCM they require an explicit cancellation step (running a nodetool command).
Whether consensus decrees that this constitutes a major bump or not, I think decoupling these major projects from 5.0 is the right move. > On 23 Oct 2023, at 12:57, Benedict <bened...@apache.org> wrote: > > I’m cool with this. > > We may have to think about numbering as I think TCM will break some backwards > compatibility and we might technically expect the follow-up release to be 6.0 > > Maybe it’s not so bad to have such rapid releases either way. > >> On 23 Oct 2023, at 12:52, Mick Semb Wever <m...@apache.org> wrote: >> >> >> >> The TCM work (CEP-21) is in its review stage but being well past our cut-off >> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to >> propose the following. >> >> We merge TCM and Accord only to trunk. Then branch cassandra-5.1 and cut an >> immediate 5.1-alpha1 release. >> >> I see this as a win-win scenario for us, considering our current situation. >> (Though it is unfortunate that Accord is included in this scenario because >> we agreed it to be based upon TCM.) >> >> This will mean… >> - We get to focus on getting 5.0 to beta and GA, which already has a ton of >> features users want. >> - We get an alpha release with TCM and Accord into users hands quickly for >> broader testing and feedback. >> - We isolate GA efforts on TCM and Accord – giving oss and downstream >> engineers time and patience reviewing and testing. TCM will be the biggest >> patch ever to land in C*. >> - Give users a choice for a more incremental upgrade approach, given just >> how many new features we're putting on them in one year. >> - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all >> 4.x versions, just as if it had landed in 5.0. >> >> >> The risks/costs this introduces are >> - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch, and >> at some point decide to undo this work, while we can throw away the >> cassandra-5.1 branch we would need to do a bit of work reverting the changes >> in trunk. This is a _very_ edge case, as confidence levels on the design >> and implementation of both are already tested and high. >> - We will have to maintain an additional branch. I propose that we treat >> the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0 >> and 3.11). This also adds the merge path overhead. >> - Reviewing of TCM and Accord will continue to happen post-merge. This is >> not our normal practice, but this work will have already received its two >> +1s from committers, and such ongoing review effort is akin to GA >> stabilisation work on release branches. >> >> >> I see no other ok solution in front of us that gets us at least both the 5.0 >> beta and TCM+Accord alpha releases this year. Keeping in mind users demand >> to start experimenting with these features, and our Cassandra Summit in >> December. >> >> >> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3 >> >>
