> 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. I'm curious to hear more about this.
> What is it going to take to get it into 5.0? What is off track and how did we > get here? I'm going to crystal-ball a combination of "we're in mythical man-month territory" and "we're doing something that's never been done before on a code-base that's a decade and a half old. In a distributed system. That takes (often unpredictable) time." I'm +1 to what you've laid out here Mick. The idea of having another branch to merge through makes me sad, but it's worth it to both get 5.0 into users' hands around our committed cadence + also get an alpha of these new features into their hands as well IMO. On Mon, Oct 23, 2023, at 11:14 AM, Paulo Motta wrote: > 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 >>>>>> >>>>>>
