+1 to 6.0 And David makes a good point about making sure that we support 4.x to 6.0 upgrades.
Thanks, Aaron On Fri, Apr 11, 2025 at 1:03 AM guo Maxwell <cclive1...@gmail.com> wrote: > +1 to 6.0 > > Berenguer Blasi <berenguerbl...@gmail.com> 于2025年4月11日周五 13:53写道： > >> +1 6.0 >> On 10/4/25 23:57, David Capwell wrote: >> >> +1 to 6.0 >> Strong +1 to T-3, we should support 4.0/4.1 to 6.0 upgrades. >> >> On Apr 10, 2025, at 2:18 PM, C. Scott Andreas <sc...@paradoxica.net> >> <sc...@paradoxica.net> wrote: >> >> +1 6.0 >> >> - Scott >> >> — >> Mobile >> >> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna <jeremy.hanna1...@gmail.com> >> <jeremy.hanna1...@gmail.com> wrote: >> >> +1 for 6.0 for TCM/Accord changes, making it easier to make a case to >> upgrade dependencies like the Java/Python versions. >> >> On Apr 10, 2025, at 3:24 PM, Bernardo Botella >> <conta...@bernardobotella.com> <conta...@bernardobotella.com> wrote: >> >> +1 on 6.0 >> >> On Apr 10, 2025, at 1:07 PM, Josh McKenzie <jmcken...@apache.org> >> <jmcken...@apache.org> wrote: >> >> Let's keep this thread to just +1's on 6.0; I'll see about a proper >> isolated [DISCUSS] thread for my proposal above hopefully tomorrow, >> schedule permitting. >> >> On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote: >> >> +1 to 6.0 >> >> On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie <jmcken...@apache.org> >> wrote: >> >> >> +1 to 6.0. >> >> On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad 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. >> >> >> >> >>
