>From a user perspective I have to say I was excited to see Accord/TCM being released on 5.0 but at the same time a little nervous about seeing so many overhauling features being shipped on the same release.
I think rushing last minute features hurts the stability goals we set for the project. As far as I understand, we have agreed to have a "release train" model where everything ready by the release date is shipped and anything else slips to the next version. 5.0 will bring a number of exciting innovations and I don't think not including TCM/Accord can be considered a disaster. I think letting the community test the currently shipped features separately from TCM/Accord will be a benefit from a stability perspective without hurting the project momentum. I think TCM/Accord are such major and long awaited improvements to the project that deserve its own exclusive release, otherwise they can easily shadow the other exciting features being shipped. I don't see any issue in performing an earlier release next year if TCM/Accord is ready by then. Regarding the versioning scheme, if we follow the versioning scheme we have defined "by the book" then TCM/Accord would belong to a 6.0 version, which I have to admit feels a bit weird but it would signal to the user community that a major change is being introduced. I don't feel strongly about this so would be fine with a 5.1 even though it would be a departure from the new versioning scheme we have agreed upon. On Mon, Oct 23, 2023 at 10:55 AM Patrick McFadin <pmcfa...@gmail.com> wrote: > 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 >>> >>> >>> >>>
