I’m going to be clearer in my statement. This has to be in 5.0, even if it’s alpha and ships after December, or this is going to be disaster that will take us much longer to unravel.
On Mon, Oct 23, 2023 at 7:49 AM Jeremiah Jordan <jeremiah.jor...@gmail.com> wrote: > +1 from me assuming we have tickets and two committer +1’s on them for > everything being committed to trunk, and CI is working/passing before it > merges. The usual things, but I want to make sure we do not compromise on > any of them as we try to “move fast” here. > > -Jeremiah Jordan > > On Oct 23, 2023 at 8:50:46 AM, Sam Tunnicliffe <s...@beobal.com> wrote: > >> +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 >> >> >> >>
