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. >>>> >>>>
