+1 on 6.0
> On Apr 10, 2025, at 1:07 PM, Josh McKenzie <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
>> <mailto: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
>>> <mailto: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.
