IIRC one of the reasons that was raised to bump to 5.0 was because of Accord. We realised latter when we pushed TCM and Accord out that the version bump may have been premature (though the other opinion around versioning remains around what upgrade paths we say we support being based on what upgrade paths we run through CI, and those being bound by jvm-dtest-upgrade's nature of where we support an overlapping jdk).
I'm not blocking on calling this release 6.0. I don't care about the number that accompanies the new features that land, I do care about our testing of upgrade paths (cluster availability during upgrades, on our recommended upgrade paths, should be paramount imho). Adding jdk21 and removing jdk11 is justification for 6.0, but this is just my opinion / what i care about. I've also heard valid reasons for TCM warranting the 6.0 version. And I appreciate the need for the outside world to have more consistency/preparation on what our next version is, otherwise I wouldn't see the rush to decide that version until we're feature-freezed and closer to release branching time. Back to Josh's proposal, let's please just remove the need for the discussion and these long conversations altogether :-) On Thu, 10 Apr 2025 at 21:15, Jordan West <jw...@apache.org> wrote: > I don’t think there is any world where we can justify such major changes > being called 5.1. 5.0 had significantly less major changes. Mick, the > topics you bring up are important. But I don’t think they are required for > the community to decide we are calling this 6.0. We’ve tried that approach > and we’ve gone in circles. We should start new threads to prioritize those > discussions while closing the naming out. It’s taken way too long and it > confuses the community imo. > > Jordan > > On Thu, Apr 10, 2025 at 12:02 Mick Semb Wever <m...@apache.org> wrote: > >> Rather than only tackle this one-off, can we please put energy into >> Josh's proposal raised above. >> >> This discussion has both technical implications (tcm, accord, jdk21, >> jvm-dtest-upgrades, …), legitimate external-facing communication concerns, >> and people's general opinions. I thought Josh's proposal captured all >> these well and is a win-win for everyone. It would be nice not to have to >> repeat this conversation :D >> >> >> >> >> On Thu, 10 Apr 2025 at 20:39, Štefan Miklošovič <smikloso...@apache.org> >> wrote: >> >>> +1, I am also getting questions about the versioning recently and people >>> themselves do not know what to call the next version like. >>> >>> On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad <j...@rustyrazorblade.com> >>> wrote: >>> >>>> Bringing this back up. >>>> >>>> I don't think we have any reason to hold up renaming the version. We >>>> can have a separate discussion about what upgrade paths are supported, but >>>> let's at least address this one issue of version number so we can have >>>> consistent messaging. When i talk to people about the next release, I'd >>>> like to be consistent with what I call it, and have a unified voice as a >>>> project. >>>> >>>> Jon >>>> >>>> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever <m...@apache.org> wrote: >>>> >>>>> . >>>>> >>>>> >>>>>> If you mean only 4.1 and 5.0 would be online upgrade targets, I would >>>>>> suggest we change that to T-3 so you encompass all “currently supported” >>>>>> releases at the time the new branch is GAed. >>>>>> >>>>>> I think that's better actually, yeah. I was originally thinking T-2 >>>>>> from the "what calendar time frame is reasonable" perspective, but saying >>>>>> "if you're on a currently supported branch you can upgrade to a release >>>>>> that comes out" makes clean intuitive sense. That'd mean: >>>>>> >>>>>> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. >>>>>> API compatible guaranteed w/5.0. >>>>>> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. >>>>>> API compatible guaranteed w/6.0. >>>>>> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. >>>>>> API compatible guaranteed w/7.0. >>>>>> >>>>> >>>>> >>>>> >>>>> I like this. >>>>> >>>>>
