Re: [DISCUSS] 5.1 should be 6.0

[Patrick McFadin]

+1 to 6.0

On Fri, Apr 11, 2025 at 8:22 AM Josh McKenzie  wrote:

> David makes a good point about making sure that we support 4.x to 6.0
> upgrades.
>
> Supporting live upgrades from every GA supported version
>  today seems obvious as a
> lazy consensus to me. Given how confusing our release versioning has been
> it's worth explicitly calling that out.
>
>
> On Fri, Apr 11, 2025, at 10:33 AM, Aaron wrote:
>
> +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  wrote:
>
> +1 to 6.0
>
> Berenguer Blasi  于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 
>  wrote:
>
> +1 6.0
>
> - Scott
>
> —
> Mobile
>
> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna 
>  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
>   wrote:
>
> +1 on 6.0
>
> On Apr 10, 2025, at 1:07 PM, Josh McKenzie 
>  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 
> 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  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.
>
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Aaron]

+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  wrote:

> +1 to 6.0
>
> Berenguer Blasi  于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 
>>  wrote:
>>
>> +1 6.0
>>
>> - Scott
>>
>> —
>> Mobile
>>
>> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna 
>>  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
>>   wrote:
>>
>> +1 on 6.0
>>
>> On Apr 10, 2025, at 1:07 PM, Josh McKenzie 
>>  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 
>> 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  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.
>>
>>
>>
>>
>>

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

> David makes a good point about making sure that we support 4.x to 6.0 
> upgrades.
Supporting live upgrades from every GA supported version 
 today seems obvious as a lazy 
consensus to me. Given how confusing our release versioning has been it's worth 
explicitly calling that out.


On Fri, Apr 11, 2025, at 10:33 AM, Aaron wrote:
> +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  wrote:
>> +1 to 6.0 
>> 
>> Berenguer Blasi  于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  
> wrote:
> 
> +1 6.0
> 
> - Scott
> 
> —
> Mobile
> 
>> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna  
>> 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 
>>>  wrote:
>>> 
>>> +1 on 6.0
>>> 
 On Apr 10, 2025, at 1:07 PM, Josh McKenzie  
 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  
> 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  
>>> 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.

Re: [DISCUSS] 5.1 should be 6.0

[guo Maxwell]

+1 to 6.0

Berenguer Blasi  于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 
>  wrote:
>
> +1 6.0
>
> - Scott
>
> —
> Mobile
>
> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna 
>  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
>   wrote:
>
> +1 on 6.0
>
> On Apr 10, 2025, at 1:07 PM, Josh McKenzie 
>  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 
> 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  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.
>
>
>
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Berenguer Blasi]

+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  
wrote:


+1 6.0

- Scott

—
Mobile

On Apr 10, 2025, at 1:34 PM, Jeremy Hanna 
 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 
 wrote:


+1 on 6.0

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

Re: [DISCUSS] 5.1 should be 6.0

[David Capwell]

+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  wrote:
> 
> +1 6.0
> 
> - Scott
> 
> —
> Mobile
> 
>> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna  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 
>>>  wrote:
>>> 
>>> +1 on 6.0
>>> 
 On Apr 10, 2025, at 1:07 PM, Josh McKenzie  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  > 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 > > 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.
>>> 
>> 

Re: [DISCUSS] 5.1 should be 6.0

[C. Scott Andreas]

+1 6.0- Scott—MobileOn Apr 10, 2025, at 1:34 PM, Jeremy Hanna  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  wrote:+1 on 6.0On Apr 10, 2025, at 1:07 PM, Josh McKenzie  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.0On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie  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.JonOn Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  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.

Re: [DISCUSS] 5.1 should be 6.0

[Jeremy Hanna]

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

Re: [DISCUSS] 5.1 should be 6.0

[Bernardo Botella]

+1 on 6.0

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

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

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

Re: [DISCUSS] 5.1 should be 6.0

[Jeremiah Jordan]

+1 to 6.0

On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie  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  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.
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

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

Re: [DISCUSS] 5.1 should be 6.0

[Jordan West]

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

Re: [DISCUSS] 5.1 should be 6.0

[Jordan West]

I am +1 on 6.0 as well. The other topics brought up on this thread are
important, and we should address them, but I think we can move forward with
the version decision in parallel.

Jordan

On Thu, Apr 10, 2025 at 11:50 AM Brad  wrote:

> > . I assume JDK 21 may lead to removal of JDK 11 which is breaking change
>
> If we name it 6.0, I would hope we bump both Java and Python supported
> versions to align with their EOL status.
>
>- Java 11 with OpenJDK EOL was October 2024
>- Python 3.8 EOL was October 7, 2024
>
>
> On Thu, Apr 10, 2025 at 2:44 PM Ekaterina Dimitrova 
> wrote:
>
>> +1 on calling it 6.0. I assume JDK 21 may lead to removal of JDK 11 which
>> is breaking change (people need to upgrade to the common JDK version - 17
>> before upgrading to the next release)
>>
>> On Thu, 10 Apr 2025 at 14:40, Štefan Miklošovič 
>> 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 
>>> 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  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.
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

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

Re: [DISCUSS] 5.1 should be 6.0

[Brad]

> . I assume JDK 21 may lead to removal of JDK 11 which is breaking change

If we name it 6.0, I would hope we bump both Java and Python supported
versions to align with their EOL status.

   - Java 11 with OpenJDK EOL was October 2024
   - Python 3.8 EOL was October 7, 2024


On Thu, Apr 10, 2025 at 2:44 PM Ekaterina Dimitrova 
wrote:

> +1 on calling it 6.0. I assume JDK 21 may lead to removal of JDK 11 which
> is breaking change (people need to upgrade to the common JDK version - 17
> before upgrading to the next release)
>
> On Thu, 10 Apr 2025 at 14:40, Štefan Miklošovič 
> 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 
>> 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  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.

Re: [DISCUSS] 5.1 should be 6.0

[Ekaterina Dimitrova]

+1 on calling it 6.0. I assume JDK 21 may lead to removal of JDK 11 which
is breaking change (people need to upgrade to the common JDK version - 17
before upgrading to the next release)

On Thu, 10 Apr 2025 at 14:40, Štefan Miklošovič 
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 
> 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  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.
>>>
>>>

Re: [DISCUSS] 5.1 should be 6.0

[Štefan Miklošovič]

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

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

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

Re: [DISCUSS] 5.1 should be 6.0

[Jon Haddad]

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

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

.


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

Re: [DISCUSS] 5.1 should be 6.0

[Jon Haddad]

Josh - from a community / user perspective, I think what you just described
is a win.  I have no clue what it means in the context of the actual work
that needs to be done, so I'll leave that aspect to others to comment on.

I could see a world where a 5.1 makes sense - but only if it was offering
incremental improvements over 5.0.  Something like JDK 21 support, rather
than a bunch of new features, and certainly not TCM / Accord.

Jon

On Wed, Jan 29, 2025 at 1:32 PM Josh McKenzie  wrote:

> My opinion is that it would be valuable to take this discussion as a
> forcing function to determine how we plan to handle releases broadly to
> answer the "5.1 should be 6.0" question. Assuming we move away from ad hoc
> per-release debate. If there's broad strong dissent (i.e. let's have 6.0 be
> the next major and talk about this topic separately) I'm happy to open
> another thread, but I didn't see clear consensus on this thread yet and was
> trying to help drive to that.
>
> Depending on what “T-2” means for the online upgrade.
>
> For 6.0, that would mean last 2 majors (5.0, 4.1). I think we'd need to
> make an exception for 4.0 during the change much like we made exceptions
> for 3.0 and 3.x, meaning T-3 to respect the current paradigm of "any
> adjacent major.minor to next major" during this transition.
>
> For 7.0, online upgrade would be supported for 6.0 and 5.0.
>
> 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.
>
> On Wed, Jan 29, 2025, at 12:15 PM, Jeremiah Jordan wrote:
>
> This got way off topic from 5.1 should be 6.0, so maybe there should be a
> new DISCUSS thread with the correct title to have a discussion around
> codifying our upgrade paths?
>
> FWIW this mostly agrees with my thoughts around upgrade support.
>
> T-2 online upgrade supported, T-1 API compatible, deprecate-then-remove is
> a combination of 3 simple things that I think will improve this situation
> greatly and hopefully put a nail in the coffin of the topic, improve
> things, and let us move on to more interesting topics that we can then
> re-litigate endlessly. ;)
>
>
> Depending on what “T-2” means for the online upgrade.  If you mean 4.0,
> 4.1, and 5.0 are all online upgrade supported versions for trunk, then I
> agree.  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.
>
> -Jeremiah
>
> On Jan 29, 2025 at 10:49:17 AM, Josh McKenzie 
> wrote:
>
>
> To clarify, when I say unspoken it includes "not consciously considered
> but shapes engagement patterns". I don't think there's people sitting
> around deeply against either the status quo or my proposal who are holding
> back for nefarious purposes or anything.
>
> And yeah - my goal is to try and put a little more energy into this to see
> if we can surface pushback as I don't think it'd be appropriate to move to
> a VOTE thread on a proposal with essentially nil engagement. My intuition
> is that the properties of the status quo isn't actually what the polity
> wants, whether or not what I'm proposing is an improvement on that status
> quo.
>
> On Wed, Jan 29, 2025, at 11:15 AM, Benedict wrote:
>
>
> I think you’re making the mistake of assuming a representative sample of
> the community participates in these debates. Sensibly, a majority of the
> community sits these out, and I think on this topic that’s actually the
> rational response.
>
> That doesn’t stop folk voting for something else when the decision
> actually matters, as it shouldn’t - the polity can’t bind itself after all.
>
> Which is only to say, I applaud your optimism but it’s probably wrong to
> assume there’ll be pushback that reifies the community’s revealed
> preferences. There’s no reason to assume there will be, and history shows
> there usually isn’t.
>
> To be clear, I don’t think these are our “unspoken incentives” but our
> collective preferences that simply can’t functionally be codified due to
> the fact nobody is willing to actually argue this is a good thing.
> Sometimes no individual likes what happens, but it’s what the polity
> actually wants, collectively. That’s fine, let’s be at peace with it.
>
> On 29 Jan 2025, at 16:00, 

Re: [DISCUSS] 5.1 should be 6.0

[Jeremiah Jordan]

On Jan 29, 2025 at 3:32:13 PM, Josh McKenzie  wrote:

> My opinion is that it would be valuable to take this discussion as a
> forcing function to determine how we plan to handle releases broadly to
> answer the "5.1 should be 6.0" question. Assuming we move away from ad hoc
> per-release debate. If there's broad strong dissent (i.e. let's have 6.0 be
> the next major and talk about this topic separately) I'm happy to open
> another thread, but I didn't see clear consensus on this thread yet and was
> trying to help drive to that.
>

We are 30 messages deep into this thread.  So I am guessing we have lost a
lot of people from it already.  If you want a broad discussion, I would
still suggest a new thread where the subject line is the broad subject you
want to discuss …

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

My opinion is that it would be valuable to take this discussion as a forcing 
function to determine how we plan to handle releases broadly to answer the "5.1 
should be 6.0" question. Assuming we move away from ad hoc per-release debate. 
If there's broad strong dissent (i.e. let's have 6.0 be the next major and talk 
about this topic separately) I'm happy to open another thread, but I didn't see 
clear consensus on this thread yet and was trying to help drive to that.

> Depending on what “T-2” means for the online upgrade. 
For 6.0, that would mean last 2 majors (5.0, 4.1). I think we'd need to make an 
exception for 4.0 during the change much like we made exceptions for 3.0 and 
3.x, meaning T-3 to respect the current paradigm of "any adjacent major.minor 
to next major" during this transition.

For 7.0, online upgrade would be supported for 6.0 and 5.0.

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

On Wed, Jan 29, 2025, at 12:15 PM, Jeremiah Jordan wrote:
> This got way off topic from 5.1 should be 6.0, so maybe there should be a new 
> DISCUSS thread with the correct title to have a discussion around codifying 
> our upgrade paths?
> 
> FWIW this mostly agrees with my thoughts around upgrade support.
> 
 T-2 online upgrade supported, T-1 API compatible, deprecate-then-remove is 
 a combination of 3 simple things that I think will improve this situation 
 greatly and hopefully put a nail in the coffin of the topic, improve 
 things, and let us move on to more interesting topics that we can then 
 re-litigate endlessly. ;)
> 
> Depending on what “T-2” means for the online upgrade.  If you mean 4.0, 4.1, 
> and 5.0 are all online upgrade supported versions for trunk, then I agree.  
> 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.
> 
> -Jeremiah
> 
> On Jan 29, 2025 at 10:49:17 AM, Josh McKenzie  wrote:
>> 
>> To clarify, when I say unspoken it includes "not consciously considered but 
>> shapes engagement patterns". I don't think there's people sitting around 
>> deeply against either the status quo or my proposal who are holding back for 
>> nefarious purposes or anything.
>> 
>> And yeah - my goal is to try and put a little more energy into this to see 
>> if we can surface pushback as I don't think it'd be appropriate to move to a 
>> VOTE thread on a proposal with essentially nil engagement. My intuition is 
>> that the properties of the status quo isn't actually what the polity wants, 
>> whether or not what I'm proposing is an improvement on that status quo.
>> 
>> On Wed, Jan 29, 2025, at 11:15 AM, Benedict wrote:
>>> 
>>> I think you’re making the mistake of assuming a representative sample of 
>>> the community participates in these debates. Sensibly, a majority of the 
>>> community sits these out, and I think on this topic that’s actually the 
>>> rational response.
>>> 
>>> That doesn’t stop folk voting for something else when the decision actually 
>>> matters, as it shouldn’t - the polity can’t bind itself after all.
>>> 
>>> Which is only to say, I applaud your optimism but it’s probably wrong to 
>>> assume there’ll be pushback that reifies the community’s revealed 
>>> preferences. There’s no reason to assume there will be, and history shows 
>>> there usually isn’t.
>>> 
>>> To be clear, I don’t think these are our “unspoken incentives” but our 
>>> collective preferences that simply can’t functionally be codified due to 
>>> the fact nobody is willing to actually argue this is a good thing. 
>>> Sometimes no individual likes what happens, but it’s what the polity 
>>> actually wants, collectively. That’s fine, let’s be at peace with it.
>>> 
 On 29 Jan 2025, at 16:00, Josh McKenzie  wrote:
 
 I've let this topic sit in my head overnight and kind of chewed on it. 
 While I agree w/the "we're doing what matches our unspoken incentives" 
 angle Benedict, I think we can do better than that both for ourselves and 
 our users if we apply energy here and codify something. If people come out 
 with energy to push *against* that codification, that'll at least bring 
 the 

Re: [DISCUSS] 5.1 should be 6.0

[Jeremiah Jordan]

 This got way off topic from 5.1 should be 6.0, so maybe there should be a
new DISCUSS thread with the correct title to have a discussion around
codifying our upgrade paths?

FWIW this mostly agrees with my thoughts around upgrade support.

T-2 online upgrade supported, T-1 API compatible, deprecate-then-remove is
> a combination of 3 simple things that I think will improve this situation
> greatly and hopefully put a nail in the coffin of the topic, improve
> things, and let us move on to more interesting topics that we can then
> re-litigate endlessly. ;)
>
>
Depending on what “T-2” means for the online upgrade.  If you mean 4.0,
4.1, and 5.0 are all online upgrade supported versions for trunk, then I
agree.  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.

-Jeremiah

On Jan 29, 2025 at 10:49:17 AM, Josh McKenzie  wrote:

> To clarify, when I say unspoken it includes "not consciously considered
> but shapes engagement patterns". I don't think there's people sitting
> around deeply against either the status quo or my proposal who are holding
> back for nefarious purposes or anything.
>
> And yeah - my goal is to try and put a little more energy into this to see
> if we can surface pushback as I don't think it'd be appropriate to move to
> a VOTE thread on a proposal with essentially nil engagement. My intuition
> is that the properties of the status quo isn't actually what the polity
> wants, whether or not what I'm proposing is an improvement on that status
> quo.
>
> On Wed, Jan 29, 2025, at 11:15 AM, Benedict wrote:
>
>
> I think you’re making the mistake of assuming a representative sample of
> the community participates in these debates. Sensibly, a majority of the
> community sits these out, and I think on this topic that’s actually the
> rational response.
>
> That doesn’t stop folk voting for something else when the decision
> actually matters, as it shouldn’t - the polity can’t bind itself after all.
>
> Which is only to say, I applaud your optimism but it’s probably wrong to
> assume there’ll be pushback that reifies the community’s revealed
> preferences. There’s no reason to assume there will be, and history shows
> there usually isn’t.
>
> To be clear, I don’t think these are our “unspoken incentives” but our
> collective preferences that simply can’t functionally be codified due to
> the fact nobody is willing to actually argue this is a good thing.
> Sometimes no individual likes what happens, but it’s what the polity
> actually wants, collectively. That’s fine, let’s be at peace with it.
>
> On 29 Jan 2025, at 16:00, Josh McKenzie  wrote:
>
> 
> I've let this topic sit in my head overnight and kind of chewed on it.
> While I agree w/the "we're doing what matches our unspoken incentives"
> angle Benedict, I think we can do better than that both for ourselves and
> our users if we apply energy here and codify something. If people come out
> with energy to push *against* that codification, that'll at least bring
> the unspoken incentives to light to work through.
>
> I think it's important we release on a predictable cadence for our users.
> We've fallen short (in some cases exceptionally) on this in the past, and
> it also adds value for operators to plan out verification and adoption
> cycles. It also helps users considering different databases to see a
> predictable cadence and a healthy project. My current position is that 12
> months is a happy medium min-value, especially with a T-2 supported cycle
> since that gives users between 12 months for high appetite fast adoption up
> to 36 months for slow verification. I don't want to further pry open
> Pandora's box, but I'd love to see us cut alphas from trunk quarterly as
> well.
>
> I also think it's important that our release versioning is clear and
> simple. Right now,  *to my mind*, it is not. The current matrix of:
>
>- Any .MINOR to next MAJOR is supported
>- Any .MAJOR to next MAJOR is supported
>- A release will be supported for some variable amount of time based
>on when we get around to new releases
>- API breaks in MAJOR changes, except when we get excited about a
>feature and want to .MAJOR to signal that in which case it may be
>completely low-risk and easy adoption, or we change JDK's and need to
>signal that, or any of another slew of caveats that require digging into
>NEWS.txt to see what the hell we're up to
>- And all of our CI pain that ensues from the above
>
> In my opinion the above is a mess. This isn't a particularly interesting
> topic to me, and us re-litigating this on every release (even if you
> discount me agitating about it; this isn't just me making noise I think),
> is a giant waste of time and energy for a low value outcome.
>
> T-2 online upgrade supported, T-1 API compatible, deprecate-then-remove is
> a combination of 3 

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

To clarify, when I say unspoken it includes "not consciously considered but 
shapes engagement patterns". I don't think there's people sitting around deeply 
against either the status quo or my proposal who are holding back for nefarious 
purposes or anything.

And yeah - my goal is to try and put a little more energy into this to see if 
we can surface pushback as I don't think it'd be appropriate to move to a VOTE 
thread on a proposal with essentially nil engagement. My intuition is that the 
properties of the status quo isn't actually what the polity wants, whether or 
not what I'm proposing is an improvement on that status quo.

On Wed, Jan 29, 2025, at 11:15 AM, Benedict wrote:
> 
> I think you’re making the mistake of assuming a representative sample of the 
> community participates in these debates. Sensibly, a majority of the 
> community sits these out, and I think on this topic that’s actually the 
> rational response.
> 
> That doesn’t stop folk voting for something else when the decision actually 
> matters, as it shouldn’t - the polity can’t bind itself after all.
> 
> Which is only to say, I applaud your optimism but it’s probably wrong to 
> assume there’ll be pushback that reifies the community’s revealed 
> preferences. There’s no reason to assume there will be, and history shows 
> there usually isn’t.
> 
> To be clear, I don’t think these are our “unspoken incentives” but our 
> collective preferences that simply can’t functionally be codified due to the 
> fact nobody is willing to actually argue this is a good thing. Sometimes no 
> individual likes what happens, but it’s what the polity actually wants, 
> collectively. That’s fine, let’s be at peace with it.
> 
>> On 29 Jan 2025, at 16:00, Josh McKenzie  wrote:
>> 
>> I've let this topic sit in my head overnight and kind of chewed on it. While 
>> I agree w/the "we're doing what matches our unspoken incentives" angle 
>> Benedict, I think we can do better than that both for ourselves and our 
>> users if we apply energy here and codify something. If people come out with 
>> energy to push *against* that codification, that'll at least bring the 
>> unspoken incentives to light to work through.
>> 
>> I think it's important we release on a predictable cadence for our users. 
>> We've fallen short (in some cases exceptionally) on this in the past, and it 
>> also adds value for operators to plan out verification and adoption cycles. 
>> It also helps users considering different databases to see a predictable 
>> cadence and a healthy project. My current position is that 12 months is a 
>> happy medium min-value, especially with a T-2 supported cycle since that 
>> gives users between 12 months for high appetite fast adoption up to 36 
>> months for slow verification. I don't want to further pry open Pandora's 
>> box, but I'd love to see us cut alphas from trunk quarterly as well.
>> 
>> I also think it's important that our release versioning is clear and simple. 
>> Right now,  *to my mind*, it is not. The current matrix of:
>>  • Any .MINOR to next MAJOR is supported
>>  • Any .MAJOR to next MAJOR is supported
>>  • A release will be supported for some variable amount of time based on 
>> when we get around to new releases
>>  • API breaks in MAJOR changes, except when we get excited about a feature 
>> and want to .MAJOR to signal that in which case it may be completely 
>> low-risk and easy adoption, or we change JDK's and need to signal that, or 
>> any of another slew of caveats that require digging into NEWS.txt to see 
>> what the hell we're up to
>>  • And all of our CI pain that ensues from the above
>> In my opinion the above is a mess. This isn't a particularly interesting 
>> topic to me, and us re-litigating this on every release (even if you 
>> discount me agitating about it; this isn't just me making noise I think), is 
>> a giant waste of time and energy for a low value outcome.
>> 
>> T-2 online upgrade supported, T-1 API compatible, deprecate-then-remove is a 
>> combination of 3 simple things that I think will improve this situation 
>> greatly and hopefully put a nail in the coffin of the topic, improve things, 
>> and let us move on to more interesting topics that we can then re-litigate 
>> endlessly. ;)
>> 
>> So - is anyone actively *against* the above proposal?
>> 
>> On Tue, Jan 28, 2025, at 11:34 AM, David Capwell wrote:
>>> I have not checked Jenkins, but we see this in another environment…
>>> 
>>> For python upgrades have we actually audited the runtime to see that the 
>>> time spent is doing real work?  Josh and I have spent a ton of time trying 
>>> to fix (and failing) an issue where the python driver blocks the test and 
>>> we wait 2 hours for that to timeout… this pattern is always after all tests 
>>> are run… what I see is python upgrades take around 30m of real work, then 
>>> 2h of idle blocking taking all resources…
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On Jan 28, 2025, at 8:16 AM, 

Re: [DISCUSS] 5.1 should be 6.0

[Benedict]

I think you’re making the mistake of assuming a representative sample of the 
community participates in these debates. Sensibly, a majority of the community 
sits these out, and I think on this topic that’s actually the rational response.

That doesn’t stop folk voting for something else when the decision actually 
matters, as it shouldn’t - the polity can’t bind itself after all.

Which is only to say, I applaud your optimism but it’s probably wrong to assume 
there’ll be pushback that reifies the community’s revealed preferences. There’s 
no reason to assume there will be, and history shows there usually isn’t.

To be clear, I don’t think these are our “unspoken incentives” but our 
collective preferences that simply can’t functionally be codified due to the 
fact nobody is willing to actually argue this is a good thing. Sometimes no 
individual likes what happens, but it’s what the polity actually wants, 
collectively. That’s fine, let’s be at peace with it.

> On 29 Jan 2025, at 16:00, Josh McKenzie  wrote:
> 
> 
> I've let this topic sit in my head overnight and kind of chewed on it. While 
> I agree w/the "we're doing what matches our unspoken incentives" angle 
> Benedict, I think we can do better than that both for ourselves and our users 
> if we apply energy here and codify something. If people come out with energy 
> to push against that codification, that'll at least bring the unspoken 
> incentives to light to work through.
> 
> I think it's important we release on a predictable cadence for our users. 
> We've fallen short (in some cases exceptionally) on this in the past, and it 
> also adds value for operators to plan out verification and adoption cycles. 
> It also helps users considering different databases to see a predictable 
> cadence and a healthy project. My current position is that 12 months is a 
> happy medium min-value, especially with a T-2 supported cycle since that 
> gives users between 12 months for high appetite fast adoption up to 36 months 
> for slow verification. I don't want to further pry open Pandora's box, but 
> I'd love to see us cut alphas from trunk quarterly as well.
> 
> I also think it's important that our release versioning is clear and simple. 
> Right now,  to my mind, it is not. The current matrix of:
> Any .MINOR to next MAJOR is supported
> Any .MAJOR to next MAJOR is supported
> A release will be supported for some variable amount of time based on when we 
> get around to new releases
> API breaks in MAJOR changes, except when we get excited about a feature and 
> want to .MAJOR to signal that in which case it may be completely low-risk and 
> easy adoption, or we change JDK's and need to signal that, or any of another 
> slew of caveats that require digging into NEWS.txt to see what the hell we're 
> up to
> And all of our CI pain that ensues from the above
> In my opinion the above is a mess. This isn't a particularly interesting 
> topic to me, and us re-litigating this on every release (even if you discount 
> me agitating about it; this isn't just me making noise I think), is a giant 
> waste of time and energy for a low value outcome.
> 
> T-2 online upgrade supported, T-1 API compatible, deprecate-then-remove is a 
> combination of 3 simple things that I think will improve this situation 
> greatly and hopefully put a nail in the coffin of the topic, improve things, 
> and let us move on to more interesting topics that we can then re-litigate 
> endlessly. ;)
> 
> So - is anyone actively against the above proposal?
> 
> On Tue, Jan 28, 2025, at 11:34 AM, David Capwell wrote:
>> I have not checked Jenkins, but we see this in another environment…
>> 
>> For python upgrades have we actually audited the runtime to see that the 
>> time spent is doing real work?  Josh and I have spent a ton of time trying 
>> to fix (and failing) an issue where the python driver blocks the test and we 
>> wait 2 hours for that to timeout… this pattern is always after all tests are 
>> run… what I see is python upgrades take around 30m of real work, then 2h of 
>> idle blocking taking all resources…
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Jan 28, 2025, at 8:16 AM, Benedict  wrote:
>>> 
>>> 
>>> My opinion? Our revealed preferences don’t match whatever ideal is being 
>>> chased whenever we discuss a policy.
>>> .
>>> Ignoring the tick-tick debacle the community has done basically the same 
>>> thing every release, only with a drift towards stricter QA and 
>>> compatibility expectations with maturity.
>>> 
>>> That is, we have always numbered using some combination of semver and how 
>>> exciting the release is, and backed all other decisions out of whatever was 
>>> reasonable once that decision was made.
>>> 
>>> Which basically means a new major every 1 or 2 releases depending on how 
>>> big the new features are. Which is actually pretty intuitive really, but 
>>> isn’t a policy anyone dogmatic wants to argue for.
>>> 
 On 28 Jan 2025, at 16:07, Josh 

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

I've let this topic sit in my head overnight and kind of chewed on it. While I 
agree w/the "we're doing what matches our unspoken incentives" angle Benedict, 
I think we can do better than that both for ourselves and our users if we apply 
energy here and codify something. If people come out with energy to push 
*against* that codification, that'll at least bring the unspoken incentives to 
light to work through.

I think it's important we release on a predictable cadence for our users. We've 
fallen short (in some cases exceptionally) on this in the past, and it also 
adds value for operators to plan out verification and adoption cycles. It also 
helps users considering different databases to see a predictable cadence and a 
healthy project. My current position is that 12 months is a happy medium 
min-value, especially with a T-2 supported cycle since that gives users between 
12 months for high appetite fast adoption up to 36 months for slow 
verification. I don't want to further pry open Pandora's box, but I'd love to 
see us cut alphas from trunk quarterly as well.

I also think it's important that our release versioning is clear and simple. 
Right now,  *to my mind*, it is not. The current matrix of:
 • Any .MINOR to next MAJOR is supported
 • Any .MAJOR to next MAJOR is supported
 • A release will be supported for some variable amount of time based on when 
we get around to new releases
 • API breaks in MAJOR changes, except when we get excited about a feature and 
want to .MAJOR to signal that in which case it may be completely low-risk and 
easy adoption, or we change JDK's and need to signal that, or any of another 
slew of caveats that require digging into NEWS.txt to see what the hell we're 
up to
 • And all of our CI pain that ensues from the above
In my opinion the above is a mess. This isn't a particularly interesting topic 
to me, and us re-litigating this on every release (even if you discount me 
agitating about it; this isn't just me making noise I think), is a giant waste 
of time and energy for a low value outcome.

T-2 online upgrade supported, T-1 API compatible, deprecate-then-remove is a 
combination of 3 simple things that I think will improve this situation greatly 
and hopefully put a nail in the coffin of the topic, improve things, and let us 
move on to more interesting topics that we can then re-litigate endlessly. ;)

So - is anyone actively *against* the above proposal?

On Tue, Jan 28, 2025, at 11:34 AM, David Capwell wrote:
> I have not checked Jenkins, but we see this in another environment…
> 
> For python upgrades have we actually audited the runtime to see that the time 
> spent is doing real work?  Josh and I have spent a ton of time trying to fix 
> (and failing) an issue where the python driver blocks the test and we wait 2 
> hours for that to timeout… this pattern is always after all tests are run… 
> what I see is python upgrades take around 30m of real work, then 2h of idle 
> blocking taking all resources…
> 
> 
> Sent from my iPhone
> 
>> On Jan 28, 2025, at 8:16 AM, Benedict  wrote:
>> 
>> 
>> My opinion? Our revealed preferences don’t match whatever ideal is being 
>> chased whenever we discuss a policy.
>> .
>> Ignoring the tick-tick debacle the community has done basically the same 
>> thing every release, only with a drift towards stricter QA and compatibility 
>> expectations with maturity.
>> 
>> That is, we have always numbered using some combination of semver and how 
>> exciting the release is, and backed all other decisions out of whatever was 
>> reasonable once that decision was made.
>> 
>> Which basically means a new major every 1 or 2 releases depending on how big 
>> the new features are. Which is actually pretty intuitive really, but isn’t a 
>> policy anyone dogmatic wants to argue for.
>> 
>>> On 28 Jan 2025, at 16:07, Josh McKenzie  wrote:
>>> 
 We revisit this basically every year and so I’m sort of inclined to keep 
 the status quo which really amounts to basically doing whatever we end up 
 deciding arbitrarily before we actually cut a release. 
 
 Before discussing at length a new policy we’ll only immediately break
>>> It's painful how accurate this feels. =/
>>> 
>>> Is it the complexity of these topics that's keeping us stuck or a lack of 
>>> consensus... or both?
>>> 
 if the motivation is
>>> My personal motivation is that our ad hoc re-litigating of this reactively 
>>> at the last possible moment over and over is uninteresting and feels like a 
>>> giant waste of time and energy for all of us. But to your point, if trying 
>>> to formalize it doesn't yield results, that's just objectively worse since 
>>> it's adding more churn on top of a churn-heavy process. /sigh
>>> 
>>> On Tue, Jan 28, 2025, at 11:01 AM, Benedict wrote:
 
 We revisit this basically every year and so I’m sort of inclined to keep 
 the status quo which really amounts to basically doing whatever we end up 
 deciding 

Re: [DISCUSS] 5.1 should be 6.0

[Benedict]

I agree there’s probably some value captured in having ccm tests, but I suspect 
not in most of the python tests we have, which are all but unmaintained at this 
point. When I looked at them last I was surprised at how rubbish many of them 
were.

I think we need a plan to maintain them properly, and ensure they actually 
offer some value.

Personally my proposal on that front is that we get rid of them (except if 
demonstrably testing some unique edge case) and instead run Harry against a ccm 
cluster we upgrade during the run.



> On 28 Jan 2025, at 16:16, Mick Semb Wever  wrote:
> 
> 
> replies inline…
>  .
>  
> 
>>> We have far fewer (and more effective?) JVM Upgrade DTests.
>>> There we only need 8x medium (3 cpu, 5GB ram) servers
>> Does anyone have a strong understanding of the coverage and value offered by 
>> the python upgrade dtests vs. the in-jvm dtests? I don't, but I intuitively 
>> have a hard time believing the value difference matches the hardware 
>> requirement difference there.
> 
> 
> I believe they are a lot more efficient – it's only to look at how tests fail 
> (versus time out).
> But the biggest factor by far is the coverage that python upgrade dtests 
> have. 
> 
> It's been questioned whether they break with legit failures.  They do.  
> There's way too much weird shit between versions, pre-commit testing has to 
> be our best tactic here, especially as we get more committers.
> 
> Also failures can be flakies that take multiple builds before a release to be 
> noticed.  And our CI system is already so saturated that our post-commit 
> builds are not that far off weekly builds anyway (i.e. nightly/weekly 
> schedule wouldn't save us anything, probably just add more load).
> 
>  
>  
>> … I'm curious if the community sees a major flaw with a proposal like the 
>> following:
>> We formally support 3 releases at a time
>> We only release MAJOR (i.e. semver major). No more "5.0, 5.1, 5.2", would 
>> now be "5.0, 6.0, 7.0"
>> We test and support online upgrades between supported releases
>> Any removal or API breakage follows a "deprecate-then-release" cycle
>> We cut a release every 12 months
>> Implications for operators:
>> Upgrade paths for online upgrades are simple and clear. T-2.
>> "Forced" update cadence to stay on supported versions is 3 years
>> If you adopt v1.0 it will be supported until v4.0 comes out 36 months later
>> This gives users the flexibility to prioritize functionality vs. stability 
>> and to balance release validation costs
>> Deprecation cycles are clear as are compatibility paths.
>> Release timelines and feature availability are predictable and clear
>> Implications for developers on the project:
>> Support requirements for online upgrades are clear
>> Opportunity cost of feature slippage relative to release date is balanced 
>> (worst-case == 11.99 month delay on availability in GA supported release)
>> Path to keep code-base maintainable is clear (deprecate-then-remove)
>> CI requirements are constrained and predictable
> 
> 
> 
> FTR this^ implements my concerns stated in yesterday's post.
> 
> 
> Small concerns are…
> 
>  - We need/should document the change (e.g. before X we did this, after X we 
> did that…).  I like that it's a proposal that avoids any need for 
> documentation around arbitrary major versions – which no one has offered to 
> take on).
> 
>  - The T-2 is fixed, where using major versions gives us more flexibility.  I 
> don't object to that at all, but it's worth highlighting.
> 
>  - When would T-2 kick in ?  Would 6.0 mean everything from 4.0 (despite that 
> kinda being like a one-off T-3) ? 
> 
> 
> 

Re: [DISCUSS] 5.1 should be 6.0

[David Capwell]

I have not checked Jenkins, but we see this in another environment…

For python upgrades have we actually audited the runtime to see that the time 
spent is doing real work?  Josh and I have spent a ton of time trying to fix 
(and failing) an issue where the python driver blocks the test and we wait 2 
hours for that to timeout… this pattern is always after all tests are run… what 
I see is python upgrades take around 30m of real work, then 2h of idle blocking 
taking all resources…


Sent from my iPhone

> On Jan 28, 2025, at 8:16 AM, Benedict  wrote:
> 
> 
> My opinion? Our revealed preferences don’t match whatever ideal is being 
> chased whenever we discuss a policy.
> .
> Ignoring the tick-tick debacle the community has done basically the same 
> thing every release, only with a drift towards stricter QA and compatibility 
> expectations with maturity.
> 
> That is, we have always numbered using some combination of semver and how 
> exciting the release is, and backed all other decisions out of whatever was 
> reasonable once that decision was made.
> 
> Which basically means a new major every 1 or 2 releases depending on how big 
> the new features are. Which is actually pretty intuitive really, but isn’t a 
> policy anyone dogmatic wants to argue for.
> 
>>> On 28 Jan 2025, at 16:07, Josh McKenzie  wrote:
>>> 
>> 
>>> 
>>> We revisit this basically every year and so I’m sort of inclined to keep 
>>> the status quo which really amounts to basically doing whatever we end up 
>>> deciding arbitrarily before we actually cut a release. 
>>> 
>>> Before discussing at length a new policy we’ll only immediately break
>> It's painful how accurate this feels. =/
>> 
>> Is it the complexity of these topics that's keeping us stuck or a lack of 
>> consensus... or both?
>> 
>>> if the motivation is
>> My personal motivation is that our ad hoc re-litigating of this reactively 
>> at the last possible moment over and over is uninteresting and feels like a 
>> giant waste of time and energy for all of us. But to your point, if trying 
>> to formalize it doesn't yield results, that's just objectively worse since 
>> it's adding more churn on top of a churn-heavy process. /sigh
>> 
>>> On Tue, Jan 28, 2025, at 11:01 AM, Benedict wrote:
>>> 
>>> We revisit this basically every year and so I’m sort of inclined to keep 
>>> the status quo which really amounts to basically doing whatever we end up 
>>> deciding arbitrarily before we actually cut a release. 
>>> 
>>> Before discussing at length a new policy we’ll only immediately break, if 
>>> the motivation is avoiding extra release steps, I would prefer we just 
>>> avoid extra release steps by eg running nightly upgrade tests rather than 
>>> pre commit, or making the tests faster, or waiting until the test matrix 
>>> actually causes anything to break rather than assuming it will.
>>> 
> On 28 Jan 2025, at 15:45, Josh McKenzie  wrote:
 
> Python Upgrade DTests today requires 192x large (7 cpu, 14GB ram) servers
 
> We have far fewer (and more effective?) JVM Upgrade DTests.
> There we only need 8x medium (3 cpu, 5GB ram) servers
 
 Does anyone have a strong understanding of the coverage and value offered 
 by the python upgrade dtests vs. the in-jvm dtests? I don't, but I 
 intuitively have a hard time believing the value difference matches the 
 hardware requirement difference there.
 
> Lots and lots of words about releases from mick (<3)
 Those of you who know me know my "spidey-senses" get triggered by enough 
 complexity regardless of how well justified. I feel like our release 
 process has passed this threshold for me. Been talking a lot with Mick 
 about this topic for a couple weeks and I'm curious if the community sees 
 a major flaw with a proposal like the following:
 We formally support 3 releases at a time
 We only release MAJOR (i.e. semver major). No more "5.0, 5.1, 5.2", would 
 now be "5.0, 6.0, 7.0"
 We test and support online upgrades between supported releases
 Any removal or API breakage follows a "deprecate-then-release" cycle
 We cut a release every 12 months
 Implications for operators:
 Upgrade paths for online upgrades are simple and clear. T-2.
 "Forced" update cadence to stay on supported versions is 3 years
 If you adopt v1.0 it will be supported until v4.0 comes out 36 months later
 This gives users the flexibility to prioritize functionality vs. stability 
 and to balance release validation costs
 Deprecation cycles are clear as are compatibility paths.
 Release timelines and feature availability are predictable and clear
 Implications for developers on the project:
 Support requirements for online upgrades are clear
 Opportunity cost of feature slippage relative to release date is balanced 
 (worst-case == 11.99 month delay on availability in GA supported release)
 Path to keep 

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

> We revisit this basically every year and so I’m sort of inclined to keep the 
> status quo which really amounts to basically doing whatever we end up 
> deciding arbitrarily before we actually cut a release. 
> 
> Before discussing at length a new policy we’ll only immediately break
It's painful how accurate this feels. =/

Is it the complexity of these topics that's keeping us stuck or a lack of 
consensus... or both?

> if the motivation is
My personal motivation is that our ad hoc re-litigating of this reactively at 
the last possible moment over and over is uninteresting and feels like a giant 
waste of time and energy for all of us. But to your point, if trying to 
formalize it doesn't yield results, that's just objectively worse since it's 
adding more churn on top of a churn-heavy process. /sigh

On Tue, Jan 28, 2025, at 11:01 AM, Benedict wrote:
> 
> We revisit this basically every year and so I’m sort of inclined to keep the 
> status quo which really amounts to basically doing whatever we end up 
> deciding arbitrarily before we actually cut a release. 
> 
> Before discussing at length a new policy we’ll only immediately break, if the 
> motivation is avoiding extra release steps, I would prefer we just avoid 
> extra release steps by eg running nightly upgrade tests rather than pre 
> commit, or making the tests faster, or waiting until the test matrix actually 
> causes anything to break rather than assuming it will.
> 
>> On 28 Jan 2025, at 15:45, Josh McKenzie  wrote:
>> 
>>> Python Upgrade DTests today requires 192x large (7 cpu, 14GB ram) servers
>> 
>>> We have far fewer (and more effective?) JVM Upgrade DTests.
>>> There we only need 8x medium (3 cpu, 5GB ram) servers
>> 
>> Does anyone have a strong understanding of the coverage and value offered by 
>> the python upgrade dtests vs. the in-jvm dtests? I don't, but I intuitively 
>> have a hard time believing the value difference matches the hardware 
>> requirement difference there.
>> 
>>> Lots and lots of words about releases from mick (<3)
>> Those of you who know me know my "spidey-senses" get triggered by enough 
>> complexity regardless of how well justified. I feel like our release process 
>> has passed this threshold for me. Been talking a lot with Mick about this 
>> topic for a couple weeks and I'm curious if the community sees a major flaw 
>> with a proposal like the following:
>>  • We formally support 3 releases at a time
>>  • We only release MAJOR (i.e. semver major). No more "5.0, 5.1, 5.2", would 
>> now be "5.0, 6.0, 7.0"
>>  • We test and support online upgrades between supported releases
>>  • Any removal or API breakage follows a "deprecate-then-release" cycle
>>  • We cut a release every 12 months
>> *Implications for operators:*
>>  • Upgrade paths for online upgrades are simple and clear. T-2.
>>  • "Forced" update cadence to stay on supported versions is 3 years
>>• If you adopt v1.0 it will be supported until v4.0 comes out 36 months 
>> later
>>• This gives users the flexibility to prioritize functionality vs. 
>> stability and to balance release validation costs
>>  • Deprecation cycles are clear as are compatibility paths.
>>  • Release timelines and feature availability are predictable and clear
>> *Implications for developers on the project:***
>>  • Support requirements for online upgrades are clear
>>  • Opportunity cost of feature slippage relative to release date is balanced 
>> (worst-case == 11.99 month delay on availability in GA supported release)
>>  • Path to keep code-base maintainable is clear (deprecate-then-remove)
>>  • CI requirements are constrained and predictable
>> Moving to a "online upgrades supported for everything" is something I 
>> support in principle, but would advocate we consider after getting a handle 
>> on our release process.
>> 
>> So - what do we lose if we consider the above approach?
>> 
>> On Tue, Jan 28, 2025, at 8:23 AM, Mick Semb Wever wrote:
>>> Jordan, replies inline. 
>>> 
>>> 
 To take a snippet from your email "A little empathy for our users goes a 
 long way."  While I agree clarity is important, forcing our users to 
 upgrade multiple times is not in their best interest. 
>>> 
>>> 
>>> Yes – we would be moving in that direction by now saying we aim for online 
>>> compatibility across all versions.   But how feasible that turns out to be 
>>> depends on our future actions and new versions.  
>>> 
>>> The separation between "the code maintains compatibility across all 
>>> versions" versus "we only actively test these upgrade paths so that's our 
>>> limited recommendation"  is here what lets us reduce the "forcing our users 
>>> to upgrade multiple times".  That's the "other paths may work but you're on 
>>> your own – do your homework" aspect.   This is a position that allows us to 
>>> progress into something better.
>>> 
>>> For now, and using the current status quo of major/minor usage as the 
>>> implemented example: this would 

Re: [DISCUSS] 5.1 should be 6.0

[Benedict]

My opinion? Our revealed preferences don’t match whatever ideal is being chased 
whenever we discuss a policy.
.
Ignoring the tick-tick debacle the community has done basically the same thing 
every release, only with a drift towards stricter QA and compatibility 
expectations with maturity.

That is, we have always numbered using some combination of semver and how 
exciting the release is, and backed all other decisions out of whatever was 
reasonable once that decision was made.

Which basically means a new major every 1 or 2 releases depending on how big 
the new features are. Which is actually pretty intuitive really, but isn’t a 
policy anyone dogmatic wants to argue for.

> On 28 Jan 2025, at 16:07, Josh McKenzie  wrote:
> 
>> 
>> We revisit this basically every year and so I’m sort of inclined to keep the 
>> status quo which really amounts to basically doing whatever we end up 
>> deciding arbitrarily before we actually cut a release. 
>> 
>> Before discussing at length a new policy we’ll only immediately break
> It's painful how accurate this feels. =/
> 
> Is it the complexity of these topics that's keeping us stuck or a lack of 
> consensus... or both?
> 
>> if the motivation is
> My personal motivation is that our ad hoc re-litigating of this reactively at 
> the last possible moment over and over is uninteresting and feels like a 
> giant waste of time and energy for all of us. But to your point, if trying to 
> formalize it doesn't yield results, that's just objectively worse since it's 
> adding more churn on top of a churn-heavy process. /sigh
> 
> On Tue, Jan 28, 2025, at 11:01 AM, Benedict wrote:
>> 
>> We revisit this basically every year and so I’m sort of inclined to keep the 
>> status quo which really amounts to basically doing whatever we end up 
>> deciding arbitrarily before we actually cut a release. 
>> 
>> Before discussing at length a new policy we’ll only immediately break, if 
>> the motivation is avoiding extra release steps, I would prefer we just avoid 
>> extra release steps by eg running nightly upgrade tests rather than pre 
>> commit, or making the tests faster, or waiting until the test matrix 
>> actually causes anything to break rather than assuming it will.
>> 
>>> On 28 Jan 2025, at 15:45, Josh McKenzie  wrote:
>>> 
 Python Upgrade DTests today requires 192x large (7 cpu, 14GB ram) servers
>>> 
 We have far fewer (and more effective?) JVM Upgrade DTests.
 There we only need 8x medium (3 cpu, 5GB ram) servers
>>> 
>>> Does anyone have a strong understanding of the coverage and value offered 
>>> by the python upgrade dtests vs. the in-jvm dtests? I don't, but I 
>>> intuitively have a hard time believing the value difference matches the 
>>> hardware requirement difference there.
>>> 
 Lots and lots of words about releases from mick (<3)
>>> Those of you who know me know my "spidey-senses" get triggered by enough 
>>> complexity regardless of how well justified. I feel like our release 
>>> process has passed this threshold for me. Been talking a lot with Mick 
>>> about this topic for a couple weeks and I'm curious if the community sees a 
>>> major flaw with a proposal like the following:
>>> We formally support 3 releases at a time
>>> We only release MAJOR (i.e. semver major). No more "5.0, 5.1, 5.2", would 
>>> now be "5.0, 6.0, 7.0"
>>> We test and support online upgrades between supported releases
>>> Any removal or API breakage follows a "deprecate-then-release" cycle
>>> We cut a release every 12 months
>>> Implications for operators:
>>> Upgrade paths for online upgrades are simple and clear. T-2.
>>> "Forced" update cadence to stay on supported versions is 3 years
>>> If you adopt v1.0 it will be supported until v4.0 comes out 36 months later
>>> This gives users the flexibility to prioritize functionality vs. stability 
>>> and to balance release validation costs
>>> Deprecation cycles are clear as are compatibility paths.
>>> Release timelines and feature availability are predictable and clear
>>> Implications for developers on the project:
>>> Support requirements for online upgrades are clear
>>> Opportunity cost of feature slippage relative to release date is balanced 
>>> (worst-case == 11.99 month delay on availability in GA supported release)
>>> Path to keep code-base maintainable is clear (deprecate-then-remove)
>>> CI requirements are constrained and predictable
>>> Moving to a "online upgrades supported for everything" is something I 
>>> support in principle, but would advocate we consider after getting a handle 
>>> on our release process.
>>> 
>>> So - what do we lose if we consider the above approach?
>>> 
>>> On Tue, Jan 28, 2025, at 8:23 AM, Mick Semb Wever wrote:
 Jordan, replies inline. 
 
 
 To take a snippet from your email "A little empathy for our users goes a 
 long way."  While I agree clarity is important, forcing our users to 
 upgrade multiple times is not in their best interest. 

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

replies inline…
 .


We have far fewer (and more effective?) JVM Upgrade DTests.
> There we only need 8x medium (3 cpu, 5GB ram) servers
>
> Does anyone have a strong understanding of the coverage and value offered
> by the python upgrade dtests vs. the in-jvm dtests? I don't, but I
> intuitively have a hard time believing the value difference matches the
> hardware requirement difference there.
>


I believe they are a lot more efficient – it's only to look at how tests
fail (versus time out).
But the biggest factor by far is the coverage that python upgrade dtests
have.

It's been questioned whether they break with legit failures.  They do.
There's way too much weird shit between versions, pre-commit testing has to
be our best tactic here, especially as we get more committers.

Also failures can be flakies that take multiple builds before a release to
be noticed.  And our CI system is already so saturated that our post-commit
builds are not that far off weekly builds anyway (i.e. nightly/weekly
schedule wouldn't save us anything, probably just add more load).




> … I'm curious if the community sees a major flaw with a proposal like the
> following:
>
>- We formally support 3 releases at a time
>- We only release MAJOR (i.e. semver major). No more "5.0, 5.1, 5.2",
>would now be "5.0, 6.0, 7.0"
>- We test and support online upgrades between supported releases
>- Any removal or API breakage follows a "deprecate-then-release" cycle
>- We cut a release every 12 months
>
> *Implications for operators:*
>
>- Upgrade paths for online upgrades are simple and clear. T-2.
>- "Forced" update cadence to stay on supported versions is 3 years
>- If you adopt v1.0 it will be supported until v4.0 comes out 36
>   months later
>   - This gives users the flexibility to prioritize functionality vs.
>   stability and to balance release validation costs
>- Deprecation cycles are clear as are compatibility paths.
>- Release timelines and feature availability are predictable and clear
>
> *Implications for developers on the project:*
>
>- Support requirements for online upgrades are clear
>- Opportunity cost of feature slippage relative to release date is
>balanced (worst-case == 11.99 month delay on availability in GA supported
>release)
>- Path to keep code-base maintainable is clear (deprecate-then-remove)
>- CI requirements are constrained and predictable
>
>

FTR this^ implements my concerns stated in yesterday's post.


Small concerns are…

 - We need/should document the change (e.g. before X we did this, after X
we did that…).  I like that it's a proposal that avoids any need for
documentation around arbitrary major versions – which no one has offered to
take on).

 - The T-2 is fixed, where using major versions gives us more flexibility.
I don't object to that at all, but it's worth highlighting.

 - When would T-2 kick in ?  Would 6.0 mean everything from 4.0 (despite
that kinda being like a one-off T-3) ?

Re: [DISCUSS] 5.1 should be 6.0

[Caleb Rackliffe]

Won't comment directly on the compatibility window (although I lean toward
the status quo and just requiring upgrades from the latest patch version of
a major release), but I think I've also arrived at a point where I'm not
convinced running the Python upgrade tests pre-commit is an efficient use
of resources. It's not just the hardware required, but the fact that we
have to expend mental energy to glance over the couple flaky upgrade tests
that have nothing to do with our patch, etc.

Re: [DISCUSS] 5.1 should be 6.0

[Benedict]

We revisit this basically every year and so I’m sort of inclined to keep the 
status quo which really amounts to basically doing whatever we end up deciding 
arbitrarily before we actually cut a release. 

Before discussing at length a new policy we’ll only immediately break, if the 
motivation is avoiding extra release steps, I would prefer we just avoid extra 
release steps by eg running nightly upgrade tests rather than pre commit, or 
making the tests faster, or waiting until the test matrix actually causes 
anything to break rather than assuming it will.

> On 28 Jan 2025, at 15:45, Josh McKenzie  wrote:
> 
> 
>> 
>> Python Upgrade DTests today requires 192x large (7 cpu, 14GB ram) servers
> 
>> We have far fewer (and more effective?) JVM Upgrade DTests.
>> There we only need 8x medium (3 cpu, 5GB ram) servers
> 
> Does anyone have a strong understanding of the coverage and value offered by 
> the python upgrade dtests vs. the in-jvm dtests? I don't, but I intuitively 
> have a hard time believing the value difference matches the hardware 
> requirement difference there.
> 
>> Lots and lots of words about releases from mick (<3)
> Those of you who know me know my "spidey-senses" get triggered by enough 
> complexity regardless of how well justified. I feel like our release process 
> has passed this threshold for me. Been talking a lot with Mick about this 
> topic for a couple weeks and I'm curious if the community sees a major flaw 
> with a proposal like the following:
> We formally support 3 releases at a time
> We only release MAJOR (i.e. semver major). No more "5.0, 5.1, 5.2", would now 
> be "5.0, 6.0, 7.0"
> We test and support online upgrades between supported releases
> Any removal or API breakage follows a "deprecate-then-release" cycle
> We cut a release every 12 months
> Implications for operators:
> Upgrade paths for online upgrades are simple and clear. T-2.
> "Forced" update cadence to stay on supported versions is 3 years
> If you adopt v1.0 it will be supported until v4.0 comes out 36 months later
> This gives users the flexibility to prioritize functionality vs. stability 
> and to balance release validation costs
> Deprecation cycles are clear as are compatibility paths.
> Release timelines and feature availability are predictable and clear
> Implications for developers on the project:
> Support requirements for online upgrades are clear
> Opportunity cost of feature slippage relative to release date is balanced 
> (worst-case == 11.99 month delay on availability in GA supported release)
> Path to keep code-base maintainable is clear (deprecate-then-remove)
> CI requirements are constrained and predictable
> Moving to a "online upgrades supported for everything" is something I support 
> in principle, but would advocate we consider after getting a handle on our 
> release process.
> 
> So - what do we lose if we consider the above approach?
> 
>> On Tue, Jan 28, 2025, at 8:23 AM, Mick Semb Wever wrote:
>> Jordan, replies inline. 
>> 
>> 
>> To take a snippet from your email "A little empathy for our users goes a 
>> long way."  While I agree clarity is important, forcing our users to upgrade 
>> multiple times is not in their best interest. 
>> 
>> 
>> Yes – we would be moving in that direction by now saying we aim for online 
>> compatibility across all versions.   But how feasible that turns out to be 
>> depends on our future actions and new versions.  
>> 
>> The separation between "the code maintains compatibility across all 
>> versions" versus "we only actively test these upgrade paths so that's our 
>> limited recommendation"  is here what lets us reduce the "forcing our users 
>> to upgrade multiple times".  That's the "other paths may work but you're on 
>> your own – do your homework" aspect.   This is a position that allows us to 
>> progress into something better.
>> 
>> For now, and using the current status quo of major/minor usage as the 
>> implemented example: this would progress us to no longer needing major 
>> versions (we would just test all upgrade paths for all current maintained 
>> versions, CI resources permitting).
>> The community can change over time as well, it's worth thinking about an 
>> approach that is adjustable to changing resources.  (This includes efforts 
>> required in documenting past, present, future, especially as changes are 
>> made.)
>> 
>> I emphasise, first I think we need to be focusing on maintaining 
>> compatibility in the code (and how and when we are willing/needing to break 
>> it).
>> 
>>  
>> At the same time, doesn't less testing resources primarily translate to 
>> longer test runs?
>> 
>> 
>> Too much also saturates the testing cluster to a point where tests become 
>> flaky and fail.  ci-cassandra.a.o is already better at exposing flaky tests 
>> than other systems.  This is a practicality, and it's constantly being 
>> improved, but only under volunteer time.  Donating test hardware is the 
>> simpler ask.
>>  
>> 

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

> Python Upgrade DTests today requires 192x large (7 cpu, 14GB ram) servers

> We have far fewer (and more effective?) JVM Upgrade DTests.
> There we only need 8x medium (3 cpu, 5GB ram) servers

Does anyone have a strong understanding of the coverage and value offered by 
the python upgrade dtests vs. the in-jvm dtests? I don't, but I intuitively 
have a hard time believing the value difference matches the hardware 
requirement difference there.

> Lots and lots of words about releases from mick (<3)
Those of you who know me know my "spidey-senses" get triggered by enough 
complexity regardless of how well justified. I feel like our release process 
has passed this threshold for me. Been talking a lot with Mick about this topic 
for a couple weeks and I'm curious if the community sees a major flaw with a 
proposal like the following:
 • We formally support 3 releases at a time
 • We only release MAJOR (i.e. semver major). No more "5.0, 5.1, 5.2", would 
now be "5.0, 6.0, 7.0"
 • We test and support online upgrades between supported releases
 • Any removal or API breakage follows a "deprecate-then-release" cycle
 • We cut a release every 12 months
*Implications for operators:*
 • Upgrade paths for online upgrades are simple and clear. T-2.
 • "Forced" update cadence to stay on supported versions is 3 years
   • If you adopt v1.0 it will be supported until v4.0 comes out 36 months later
   • This gives users the flexibility to prioritize functionality vs. stability 
and to balance release validation costs
 • Deprecation cycles are clear as are compatibility paths.
 • Release timelines and feature availability are predictable and clear
*Implications for developers on the project:**
*
 • Support requirements for online upgrades are clear
 • Opportunity cost of feature slippage relative to release date is balanced 
(worst-case == 11.99 month delay on availability in GA supported release)
 • Path to keep code-base maintainable is clear (deprecate-then-remove)
 • CI requirements are constrained and predictable
Moving to a "online upgrades supported for everything" is something I support 
in principle, but would advocate we consider after getting a handle on our 
release process.

So - what do we lose if we consider the above approach?

On Tue, Jan 28, 2025, at 8:23 AM, Mick Semb Wever wrote:
> Jordan, replies inline. 
> 
> 
>> To take a snippet from your email "A little empathy for our users goes a 
>> long way."  While I agree clarity is important, forcing our users to upgrade 
>> multiple times is not in their best interest. 
> 
> 
> Yes – we would be moving in that direction by now saying we aim for online 
> compatibility across all versions.   But how feasible that turns out to be 
> depends on our future actions and new versions.  
> 
> The separation between "the code maintains compatibility across all versions" 
> versus "we only actively test these upgrade paths so that's our limited 
> recommendation"  is here what lets us reduce the "forcing our users to 
> upgrade multiple times".  That's the "other paths may work but you're on your 
> own – do your homework" aspect.   This is a position that allows us to 
> progress into something better.
> 
> For now, and using the current status quo of major/minor usage as the 
> implemented example: this would progress us to no longer needing major 
> versions (we would just test all upgrade paths for all current maintained 
> versions, CI resources permitting).
> The community can change over time as well, it's worth thinking about an 
> approach that is adjustable to changing resources.  (This includes efforts 
> required in documenting past, present, future, especially as changes are 
> made.)
> 
> I emphasise, first I think we need to be focusing on maintaining 
> compatibility in the code (and how and when we are willing/needing to break 
> it).
> 
>  
>> At the same time, doesn't less testing resources primarily translate to 
>> longer test runs?
> 
> 
> Too much also saturates the testing cluster to a point where tests become 
> flaky and fail.  ci-cassandra.a.o is already better at exposing flaky tests 
> than other systems.  This is a practicality, and it's constantly being 
> improved, but only under volunteer time.  Donating test hardware is the 
> simpler ask.
>  
>> Upgrade tests don't need to be run on every commit. When I worked on Riak we 
>> had very comprehensive upgrade testing (pretty much the full matrix of 
>> versions) and we had a schedule we ran these tests on ahead of release.
> 
> 
> We are already struggling to stay on top of failures and flakies with 
> ~per-commit builds and butler.c.a.o
> I'm not against the idea of schedule test runs, but it needs more input and 
> effort from people in that space for it to accommodate it.
> 
> I am not fond of the idea of "tests ahead of release" – release managers 
> already do enough and are a scarce resource.  Asking them to also be the 
> build butler and chase down bugs and people to fix 

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

Jordan, replies inline.


To take a snippet from your email "A little empathy for our users goes a
> long way."  While I agree clarity is important, forcing our users to
> upgrade multiple times is not in their best interest.
>


Yes – we would be moving in that direction by now saying we aim for online
compatibility across all versions.   But how feasible that turns out to be
depends on our future actions and new versions.

The separation between "the code maintains compatibility across all
versions" versus "we only actively test these upgrade paths so that's our
limited recommendation"  is here what lets us reduce the "forcing our users
to upgrade multiple times".  That's the "other paths may work but you're on
your own – do your homework" aspect.   This is a position that allows us to
progress into something better.

For now, and using the current status quo of major/minor usage as the
implemented example: this would progress us to no longer needing major
versions (we would just test all upgrade paths for all current maintained
versions, CI resources permitting).

The community can change over time as well, it's worth thinking about an
approach that is adjustable to changing resources.  (This includes efforts
required in documenting past, present, future, especially as changes are
made.)

I emphasise, first I think we need to be focusing on maintaining
compatibility in the code (and how and when we are willing/needing to break
it).



> At the same time, doesn't less testing resources primarily translate to
> longer test runs?
>


Too much also saturates the testing cluster to a point where tests become
flaky and fail.  ci-cassandra.a.o is already better at exposing flaky tests
than other systems.  This is a practicality, and it's constantly being
improved, but only under volunteer time.  Donating test hardware is
the simpler ask.



> Upgrade tests don't need to be run on every commit. When I worked on Riak
> we had very comprehensive upgrade testing (pretty much the full matrix of
> versions) and we had a schedule we ran these tests on ahead of release.
>


We are already struggling to stay on top of failures and flakies with
~per-commit builds and butler.c.a.o
I'm not against the idea of schedule test runs, but it needs more input and
effort from people in that space for it to accommodate it.

I am not fond of the idea of "tests ahead of release" – release managers
already do enough and are a scarce resource.  Asking them to also be the
build butler and chase down bugs and people to fix them is not appropriate
IMO.   I also think it's unwise without guarantee that the
contributor/committer that created the bug is available at release time.
Having just one post-commit pipeline has nice benefits in simplicity, as
long as it's feasible then slow is ok (as you say above).



> Could you share some more details on the resource issues and their impacts?
>

Python Upgrade DTests and JVM Upgrade DTests.

Python Upgrade DTests today requires 192x large (7 cpu, 14GB ram) servers,
each taking up to one hour.
Currently we have too many upgrade paths (4.0, 4.1, 5.0, to trunk), and are
seeing builds abort because of timeouts (>1hr).  Collected timing numbers
suggest we should double this number to 384, or simply remove upgrade paths
we test.

https://github.com/apache/cassandra/blob/trunk/.jenkins/Jenkinsfile#L185-L188

https://github.com/apache/cassandra/blob/trunk/.jenkins/Jenkinsfile#L37

We have far fewer (and more effective?) JVM Upgrade DTests.
There we only need 8x medium (3 cpu, 5GB ram) servers.
https://github.com/apache/cassandra/blob/trunk/.jenkins/Jenkinsfile#L177

Re: [DISCUSS] 5.1 should be 6.0

[Benedict]

Yeah, my position is this isn’t a problem. The full range of upgrade tests only 
need to be run at most on release, and we’re not talking about supporting loads 
of versions. I think it’s fine to (as before) expect people upgrade from and to 
the highest patch version of any minor release, so the multiplicity of paths is 
pretty tractable.

I anyway don’t really see how this is relevant to the 6.0 vs 5.1 topic, 5.1 has 
the exact same issue to grapple with. Supported upgrade paths is its own 
discussion, and it should consider only how painful it is for us as a community 
to support a given option.

I continue to struggle to see why you want to argue it’s a problem for users to 
have more options. Anyone who thinks you need to upgrade between adjacent major 
versions loses *nothing* by us expanding the supported upgrade paths. It’s 
still true that this is safe.

> On 28 Jan 2025, at 02:24, Jordan West  wrote:
> 
> Mick,
>  
> There is a lot to respond to here and I think we might need a few other 
> threads to avoid a spidering conversation but I wanted to respond to what I 
> saw is at least part of the crux of your concern: our recommended upgrade 
> paths. To take a snippet from your email "A little empathy for our users goes 
> a long way."  While I agree clarity is important, forcing our users to 
> upgrade multiple times is not in their best interest. Several threads 
> recently have touched on why. Forcing more upgrades on users asks them to 
> take more risk. I think a lot of what you laid out makes the world of 
> upgrades similar for us Cassandra committers but not Cassandra operators 
> (whether they have 1 cluster or 10,000). 
> 
> That said, so does asking them to try upgrades we don't test. If we are going 
> to support more than "next major version" upgrades, we must test it. I don't 
> think there is a strong debate on that. I don't know how to solve the testing 
> resources problem besides to try and "fundraise" (as you suggest) for more 
> (companies that for example find the desire to skip a major important could 
> consider contributing resources to test it, although these days I recognize 
> resources for this could be slim, and I admit I wouldn't know where to start 
> myself, basically I don't want to trivialize it). At the same time, doesn't 
> less testing resources primarily translate to longer test runs? Upgrade tests 
> don't need to be run on every commit. When I worked on Riak we had very 
> comprehensive upgrade testing (pretty much the full matrix of versions) and 
> we had a schedule we ran these tests on ahead of release. Could you share 
> some more details on the resource issues and their impacts?
> 
> Jordan

Re: [DISCUSS] 5.1 should be 6.0

[Jordan West]

Mick,

There is a lot to respond to here and I think we might need a few other
threads to avoid a spidering conversation but I wanted to respond to what I
saw is at least part of the crux of your concern: our recommended upgrade
paths. To take a snippet from your email "A little empathy for our users
goes a long way."  While I agree clarity is important, forcing our users to
upgrade multiple times is not in their best interest. Several threads
recently have touched on why. Forcing more upgrades on users asks them to
take more risk. I think a lot of what you laid out makes the world of
upgrades similar for us Cassandra committers but not Cassandra operators
(whether they have 1 cluster or 10,000).

That said, so does asking them to try upgrades we don't test. If we are
going to support more than "next major version" upgrades, we must test it.
I don't think there is a strong debate on that. I don't know how to solve
the testing resources problem besides to try and "fundraise" (as you
suggest) for more (companies that for example find the desire to skip a
major important could consider contributing resources to test it, although
these days I recognize resources for this could be slim, and I admit I
wouldn't know where to start myself, basically I don't want to trivialize
it). At the same time, doesn't less testing resources primarily translate
to longer test runs? Upgrade tests don't need to be run on every commit.
When I worked on Riak we had very comprehensive upgrade testing (pretty
much the full matrix of versions) and we had a schedule we ran these tests
on ahead of release. Could you share some more details on the resource
issues and their impacts?

Jordan

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

There's still a few open loops in this thread that I'd like to keep pushing
on.

I admit I've been pretty adamant that there's real value for a) users,
operators, and ourselves, having an intuitive understanding of our
recommended upgrade paths by versions, and b) a method to reduce the CI
testing load, but it's also clear that the status quo isn't quite right yet
for all of us.

The topics I believe at hand are…

* Online versus Offline compatibility
* Testing resources required to community support many upgrade paths
* When deprecated cognitive load and tech debt does become too much
* What are we currently doing with Major vs Minor versions
* And, who are the people doing the work in these areas

I'm avoiding the marketing aspect of major versions.  I think we need to
sort out and work forward from these technical issues first, but that might
just be my opinion 🤷


=Online versus Offline compatibility

There's a push to avoid unnecessarily breaking online and offline
compatibility.   While offline compatibility has been deemed more
important, we should also aim to be online compatible forever.  This raised
the tension point that no major, or any other, version should be a license
to break compatibility or remove deprecated stuff –  we have leaned too
eagerly in this direction in 4.0 and 5.0.


=Testing resources required to community support many upgrade paths
=When deprecated cognitive load and tech debt does become too much

But we are fallible, there are bugs, accidental compatibility issues, a
build up of tech debt (cognitive load on compatibility paths), and limited
community resources to how much we can CI test, and limited doc
contributors.

I'm not keen on us recommending upgrade paths that we are not running
through CI.  Neither having to rely upon downstream users and vendors
saying opaquely what is recommended.

This isn't an either-or situation.  Let's target online compatibility in
the project, while being conservative in what we message publicly.  For
example "these are our recommended upgrade paths, other paths may work but
you're on your own – do your homework".

Then, in the project when tech debt does become too much*, or there's
unintentionally breakage or a bug, we have possibilities at hand to make
fixes a little more feasible.  And this should always be done with
consensus on the ML, and where breakages are restricted to non-recommended
upgrade paths.

*) I hope that removing tech debt (cognitive load) in the code is always
considered a valid discussion, and that we should keep in mind a codebase
that is also accessible to engineers that are not full-time employed to
work on C*.


=What are we currently doing with Major vs Minor versions

There is no desire for semver purity.  The point is if/how we might take
advantage of the major and minor distinction.  Some see it as an
opportunity for marketing.  Some see it as an opportunity to reduce our
workload and cognitive load while making life a bit easier for operators.
And others see it as meaningless and should just be removed.

It has been suggested that our upgrade paths be restricted to those
versions we currently maintain.  The problem with that is many operators
find themselves outside of these versions, and want to know what paths are
recommended or possible to get back onto a maintained version.  We cannot
assume they can make a single jump back onto a maintained version, and
leaving them out in the cold is an unfortunate f** *** to them, IMHO.  A
little empathy for our users goes a long way.

Documentation on our (recommended or strict) upgrade path should also be
available, but we don't see anyone really stepping on much on the docs
front.  Again, I don't think it's appropriate to leave it to vendors to be
documenting this for us.  The rule that we have "only upgrade between
adjacent major versions" has effectively/inadvertently been in place since
3.0 (and maybe 2.0 ?), and it is an intuitive and simple rule that avoids
us having to document much.

In an ideal world where we got good at always and forever maintaining
online compatibility, and had unlimited CI resources, we could remove the
need for this application of the distinction.

It's worth noting that our definition of compatibility can include both
hard and soft concerns.  Hard is like 3.x to 5.x simply does not work
because internode messaging incompatibility.  Soft concerns can be the jdk
version (we recommend the jdk upgrade happens separately to a major
upgrade), or like TCM where there's enough of an operational warning flag
that we would rather operators extra carefully check everything that must
be manually done.

=Who are the people doing the work in these areas

My argument has focused on the opportunity to reduce documentation
requirements, to make it that bit more intuitive for operators, and to
minimise the CI resources requirement while ensuring what we say we do we
test.  I'm probably beating the dead horse here but I have had many
conversations with 

Re: [DISCUSS] 5.1 should be 6.0

[David Capwell]

> My expectation is that in trunk SCM CASSANDRA_4 would change to SCM 
> CASSANDRA_5.

Assuming you upgrade from 4.0 to 5.0, then you are running on CASSANDRA_4… how 
many people know that they are expected to do something about that (Sam 
documented the steps earlier)?  What if you leave things alone and try to 
upgrade to 5.1/6.0… now what?

What about users who create a new 5.0 cluster… we still default to 
compatibility mode in this case, so a new 5.0 cluster is running with 
CASSANDRA_4…

> This is why I want to remove the coupling between SCM and messaging version.

Feels like we just had a similar conversation Sam with regard to TCM / Accord ;)

I don’t see messaging version as the problem, as I feel that messaging and disk 
versions are intertwined and cause this confusion (they are the same 
serializers)… If we are running with messaging version VERSION_40, why does it 
matter if we write to disk with VERSION_40 or VERSION_50?  If we want downgrade 
we should block _50 and only use _40 for disk, but why should networking not be 
allowed to do _50?  What we write to disk impacts our ability to downgrade, and 
messaging already has an ability to downgrade its version if its peers don’t 
know the latest version.

In short I agree with you Sam, we should decouple… I think it makes sense for 
SCM to control the version we use for disk, but not networking… 

> On Dec 12, 2024, at 8:46 AM, Sam Tunnicliffe  wrote:
> 
> No, we initially tried to preserve all the previous paths and put the whole 
> thing behind a feature flag, but it was just way too pervasive and doing so 
> would've added years to the project. So for the period before the CMS is 
> initialized, certain operations are not available. 
> 
> However, it should be entirely possible to downgrade and rollback to 5.0 
> after cutting over to TCM, as long as SSTables are still in the old format. 
> By "should be" I mean it is absolutely possible and has been tested, but it 
> requires the SCM to guard the on disk format, which has the unfortunate 
> effect of limiting the messaging version and that in turn make it impossible 
> to actually cut over to TCM. i.e. the testing has been done with a patch 
> which disables some things which rely on messaging VERSION_51. This is why I 
> want to remove the coupling between SCM and messaging version.
> 
> Also, I misspoke slightly in my previous email because I forgot that we did 
> manage to enable a decent subsection of TCM to work with 
> VERSION_40/VERSION_50. In this scenario, you still get the linearized schema 
> updates via the metadata log but replicas/coordinators don't exchange epochs 
> during reads/writes so the consistency guarantees are weakened.
> 
> Thanks,
> Sam
> 
> 
>> On 12 Dec 2024, at 16:17, Jeremiah Jordan  wrote:
>> 
>> My expectation is that in trunk SCM CASSANDRA_4 would change to SCM 
>> CASSANDRA_5.  I think we should be striving to support full 
>> downgrade/rollback ability to the previous major version from trunk.
>> With TCM I would expect that when running in CASSANDRA_5 mode that 
>> initializing TCM would not be possible, as once initialized you could no 
>> longer roll back.
>> Do we have no way to support the gossip paths continuing to work prior to 
>> initializing TCM?
>> 
>> -Jeremiah
>> 
>> On Dec 11, 2024 at 7:41:48 AM, Sam Tunnicliffe  wrote:
>>> My point is that the upgrade to 5.1/6.0 isn't really complete until the CMS 
>>> is initialised and this can't be done while running with SCM CASSANDRA_4 
>>> because of the messaging service limitation. Until that point, schema 
>>> changes & node replacements are not supported which affects how long a bake 
>>> time is tolerable. 
>>> This specific issue could probably be fixed by revisiting the SCM 
>>> implementation in 5.1/6.0, so we should certainly do that but the fact 
>>> remains that we don't have great test coverage to indicate how clusters 
>>> behave when running in SCM for a prolonged period.  
>>> 
>>> Thanks, 
>>> Sam
>>> 
 On 11 Dec 2024, at 13:29, Brandon Williams  wrote:
 
 On Wed, Dec 11, 2024 at 7:22 AM Sam Tunnicliffe  wrote:
> 
> so running in any SCM mode for a prolonged period is not really viable.
 
 This is what many users want to do though, upgrade one DC and let it
 bake to see how it goes before continuing.  I don't think that's
 unreasonable, but from working on CASSANDRA-20118 I know how difficult
 that is already.  I don't think we've built enough SCM muscle yet to
 think about handling multiple previous versions.
 
 Kind Regards,
 Brandon
>>> 
> 

Re: [DISCUSS] 5.1 should be 6.0

[Sam Tunnicliffe]

No, we initially tried to preserve all the previous paths and put the whole 
thing behind a feature flag, but it was just way too pervasive and doing so 
would've added years to the project. So for the period before the CMS is 
initialized, certain operations are not available. 

However, it should be entirely possible to downgrade and rollback to 5.0 after 
cutting over to TCM, as long as SSTables are still in the old format. By 
"should be" I mean it is absolutely possible and has been tested, but it 
requires the SCM to guard the on disk format, which has the unfortunate effect 
of limiting the messaging version and that in turn make it impossible to 
actually cut over to TCM. i.e. the testing has been done with a patch which 
disables some things which rely on messaging VERSION_51. This is why I want to 
remove the coupling between SCM and messaging version.

Also, I misspoke slightly in my previous email because I forgot that we did 
manage to enable a decent subsection of TCM to work with VERSION_40/VERSION_50. 
In this scenario, you still get the linearized schema updates via the metadata 
log but replicas/coordinators don't exchange epochs during reads/writes so the 
consistency guarantees are weakened.

Thanks,
Sam
 

> On 12 Dec 2024, at 16:17, Jeremiah Jordan  wrote:
> 
> My expectation is that in trunk SCM CASSANDRA_4 would change to SCM 
> CASSANDRA_5.  I think we should be striving to support full 
> downgrade/rollback ability to the previous major version from trunk.
> With TCM I would expect that when running in CASSANDRA_5 mode that 
> initializing TCM would not be possible, as once initialized you could no 
> longer roll back.
> Do we have no way to support the gossip paths continuing to work prior to 
> initializing TCM?
> 
> -Jeremiah
> 
> On Dec 11, 2024 at 7:41:48 AM, Sam Tunnicliffe  wrote:
>> My point is that the upgrade to 5.1/6.0 isn't really complete until the CMS 
>> is initialised and this can't be done while running with SCM CASSANDRA_4 
>> because of the messaging service limitation. Until that point, schema 
>> changes & node replacements are not supported which affects how long a bake 
>> time is tolerable. 
>> This specific issue could probably be fixed by revisiting the SCM 
>> implementation in 5.1/6.0, so we should certainly do that but the fact 
>> remains that we don't have great test coverage to indicate how clusters 
>> behave when running in SCM for a prolonged period.  
>> 
>> Thanks, 
>> Sam
>> 
>>> On 11 Dec 2024, at 13:29, Brandon Williams  wrote:
>>> 
>>> On Wed, Dec 11, 2024 at 7:22 AM Sam Tunnicliffe  wrote:
>>> >
>>> > so running in any SCM mode for a prolonged period is not really viable.
>>> 
>>> This is what many users want to do though, upgrade one DC and let it
>>> bake to see how it goes before continuing.  I don't think that's
>>> unreasonable, but from working on CASSANDRA-20118 I know how difficult
>>> that is already.  I don't think we've built enough SCM muscle yet to
>>> think about handling multiple previous versions.
>>> 
>>> Kind Regards,
>>> Brandon
>> 

Re: [DISCUSS] 5.1 should be 6.0

[Jeremiah Jordan]

 My expectation is that in trunk SCM CASSANDRA_4 would change to SCM
CASSANDRA_5.  I think we should be striving to support full
downgrade/rollback ability to the previous major version from trunk.
With TCM I would expect that when running in CASSANDRA_5 mode that
initializing TCM would not be possible, as once initialized you could no
longer roll back.
Do we have no way to support the gossip paths continuing to work prior to
initializing TCM?

-Jeremiah

On Dec 11, 2024 at 7:41:48 AM, Sam Tunnicliffe  wrote:

> My point is that the upgrade to 5.1/6.0 isn't really complete until the
> CMS is initialised and this can't be done while running with SCM
> CASSANDRA_4 because of the messaging service limitation. Until that point,
> schema changes & node replacements are not supported which affects how long
> a bake time is tolerable.
> This specific issue could probably be fixed by revisiting the SCM
> implementation in 5.1/6.0, so we should certainly do that but the fact
> remains that we don't have great test coverage to indicate how clusters
> behave when running in SCM for a prolonged period.
>
> Thanks,
> Sam
>
> On 11 Dec 2024, at 13:29, Brandon Williams  wrote:
>
>
> On Wed, Dec 11, 2024 at 7:22 AM Sam Tunnicliffe  wrote:
>
> >
>
> > so running in any SCM mode for a prolonged period is not really viable.
>
>
> This is what many users want to do though, upgrade one DC and let it
>
> bake to see how it goes before continuing.  I don't think that's
>
> unreasonable, but from working on CASSANDRA-20118 I know how difficult
>
> that is already.  I don't think we've built enough SCM muscle yet to
>
> think about handling multiple previous versions.
>
>
> Kind Regards,
>
> Brandon
>
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Paul Chandler]

I think there is a danger that when in comes to the next upgrade cycle there 
could be production clusters still running in CASSANDRA_4 mode, as the 
operators haven’t realised they need to move through the SCM levels. The 
default setting for a new cluster is CASSANDRA_4 and unless a new operator is 
going to use the new Cassandra 5 features they may not work out the SCM needs 
to change. 

I can also imagine that there will be a lot left in UPGRADING mode, from what I 
can work out, for a cluster working within its performance boundaries there 
seems to be no real reason to go from UGRADING -> NONE, on very large clusters 
where a rolling restart is a pain, I currently don’t see a reason for 
recommending this last step, unless it is combined with something else that 
requires a rolling restart.

SCM documentation has been hard to find, the only info I have found is in the 
NEWS.txt file, this also implies that SCM will be removed for the next release.

Thanks 
Paul

> On 11 Dec 2024, at 13:41, Sam Tunnicliffe  wrote:
> 
> My point is that the upgrade to 5.1/6.0 isn't really complete until the CMS 
> is initialised and this can't be done while running with SCM CASSANDRA_4 
> because of the messaging service limitation. Until that point, schema changes 
> & node replacements are not supported which affects how long a bake time is 
> tolerable. 
> This specific issue could probably be fixed by revisiting the SCM 
> implementation in 5.1/6.0, so we should certainly do that but the fact 
> remains that we don't have great test coverage to indicate how clusters 
> behave when running in SCM for a prolonged period.  
> 
> Thanks, 
> Sam
> 
>> On 11 Dec 2024, at 13:29, Brandon Williams  wrote:
>> 
>> On Wed, Dec 11, 2024 at 7:22 AM Sam Tunnicliffe  wrote:
>>> 
>>> so running in any SCM mode for a prolonged period is not really viable.
>> 
>> This is what many users want to do though, upgrade one DC and let it
>> bake to see how it goes before continuing.  I don't think that's
>> unreasonable, but from working on CASSANDRA-20118 I know how difficult
>> that is already.  I don't think we've built enough SCM muscle yet to
>> think about handling multiple previous versions.
>> 
>> Kind Regards,
>> Brandon
> 

Re: [DISCUSS] 5.1 should be 6.0

[Sam Tunnicliffe]

My point is that the upgrade to 5.1/6.0 isn't really complete until the CMS is 
initialised and this can't be done while running with SCM CASSANDRA_4 because 
of the messaging service limitation. Until that point, schema changes & node 
replacements are not supported which affects how long a bake time is tolerable. 
This specific issue could probably be fixed by revisiting the SCM 
implementation in 5.1/6.0, so we should certainly do that but the fact remains 
that we don't have great test coverage to indicate how clusters behave when 
running in SCM for a prolonged period.  

Thanks, 
Sam

> On 11 Dec 2024, at 13:29, Brandon Williams  wrote:
> 
> On Wed, Dec 11, 2024 at 7:22 AM Sam Tunnicliffe  wrote:
>> 
>> so running in any SCM mode for a prolonged period is not really viable.
> 
> This is what many users want to do though, upgrade one DC and let it
> bake to see how it goes before continuing.  I don't think that's
> unreasonable, but from working on CASSANDRA-20118 I know how difficult
> that is already.  I don't think we've built enough SCM muscle yet to
> think about handling multiple previous versions.
> 
> Kind Regards,
> Brandon

Re: [DISCUSS] 5.1 should be 6.0

[Brandon Williams]

On Wed, Dec 11, 2024 at 7:22 AM Sam Tunnicliffe  wrote:
>
> so running in any SCM mode for a prolonged period is not really viable.

This is what many users want to do though, upgrade one DC and let it
bake to see how it goes before continuing.  I don't think that's
unreasonable, but from working on CASSANDRA-20118 I know how difficult
that is already.  I don't think we've built enough SCM muscle yet to
think about handling multiple previous versions.

Kind Regards,
Brandon

Re: [DISCUSS] 5.1 should be 6.0

[Sam Tunnicliffe]

At present, there is one version specific mode - CASSANDRA_4. Fully utilising 
SCM during an upgrade though requires first a "soft" upgrade into CASSANDRA_4 
mode, then a full cluster bounce into UPGRADING mode and finally another into 
NONE. I think that as the list of versions we want to provide compatibility 
with grows, this process will be replicated for each one added.

To repeat Marcus' point, because the implication is that a cluster may remain 
in some SCM mode for prolonged periods, we ought to thoroughly test all 
combinations of these states and versions, but currently we are not.
e.g. We should run all test suites with C* 5.0 in CASSANDRA_4 / UPGRADING / 
NONE, and with 5.1/6.0 in CASSANDRA_4 / UPGRADING / NONE (and in CASSANDRA_5 
mode if/when we add that). Even the upgrade tests don't really consider SCM, 
aside from the ones specifically targetting it.

Aside from testing cost/complexity, we already have a problem with this in 
trunk. CASSANDRA_4 mode caps the messaging version at VERSION_40, but the 
switch to TCM requires changes to messaging formats that are gated on 
VERSION_51. Until the CMS is initialised, metadata-changing operations such as 
schema or topology changes are disallowed, so running in any SCM mode for a 
prolonged period is not really viable.  


> On 11 Dec 2024, at 12:57, Benedict  wrote:
> 
> It might not be too bad if done selectively? I agree that would be infeasible 
> for each patch.
> 
> How many SCM modes do we have?
> 
> I worry more about developer burden. It sounds like we have a balancing act 
> with SCM complexity versus upgrade complexity.
> 
> I think at the very least we should require that whatever you upgrade from 
> should be in max SCM for that version, and the upgraded version should check 
> it is brought up in the equivalent SCM for the new release until upgrade is 
> complete. Hopefully this would prevent SCM from becoming a major extra 
> dimension besides simply minor/major combinations.
> 
> 
>> On 11 Dec 2024, at 12:43, Marcus Eriksson  wrote:
>> 
>> Staying slightly off topic - we'd also have to run upgrade tests for all 
>> these upgrade combinations, including different storage compatibility mode 
>> settings, that is going to be very expensive.
>> 
>> /Marcus
>> 
>>> On Wed, Dec 11, 2024 at 12:36:02PM GMT, Sam Tunnicliffe wrote:
>>> Maybe this is not the right place to bring up practicalities, but the more 
>>> upgrade paths we support the more complexity we take on. The ongoing issues 
>>> mentioned in CASSANDRA-20118 are illustrative and the introduction of 
>>> Storage Compatibility Mode adds further dimensions and operational 
>>> complexity to any upgrade. At the very least, SCM needs decoupling from 
>>> messaging versions as in its current form it prevents new versions from 
>>> introducing any messaging format changes, regardless of any impact on 
>>> storage formats.
>>> 
>>> * Should 5.1/6.0 continue to support CASSANDRA_4 SCM? (if we are going to 
>>> support upgrades from 4.x then it has to).
>>> * Do we have any plans for CASSANDRA_5 compatibility mode when upgrading to 
>>> 5.1/6.0?
>>> * If we want to continue to allow upgrades to jump multiple versions, do we 
>>> allow any intermediate SCM setting? (i.e. go from 4.x to 6.x with SCM set 
>>> to 5?)
>>> 
>>> Sorry for going off topic re: the actual number we give to the next 
>>> release, I really don't feel strongly about 5.1 vs 6.0.
>>> 
>>> Thanks,
>>> Sam
>>> 
> On 11 Dec 2024, at 11:02, Rahul Singh (ANANT)  
> wrote:
 
 +1 for calling it 6, even if just to bring up to people on 2.x,3.x that 
 they are on "ancient" code.
 
 Sent via Superhuman iOS
 
 
> On Wed, Dec 11 2024 at 5:23 AM, Aleksey Yeshchenko  
> wrote:
 We don’t really practice canonic sermver, we never really have, and it’s 
 impossible to properly follow anyway.
 
 Should be perfectly fine to bump to 6.0, so long as we don’t take the bump 
 as a license to break compatibility in a way that we wouldn’t have for 5.1.
 
 
> On 11 Dec 2024, at 00:11, Jon Haddad  wrote:
> 
>> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now 
>> non-functioning.  And the cleaner code certainly helps navigate the code 
>> base quicker.
> 
> Sure - I was using that as an example, looking back in hindsight.  Like, 
> if today people could go from 2.1 -> 5.0 it would be cool.  Applying it 
> to the future, if someone could go from 4.1 to 7.0, that would be nice.
> 
> I have no clue what that means for maintenance.  If it slowed development 
> time down, it becomes less useful.  
> 
> Jon
> 
> 
> 
> 
> 
> 
> 
> On Tue, Dec 10, 2024 at 3:57 PM Mick Semb Wever  wrote:
> 
> 
> I know a few teams on 2.2 that would *love* to be able to jump right to 
> 5.0.  Once you fall far enough behind, upgrading to another version 
> that's already 

Re: [DISCUSS] 5.1 should be 6.0

[Benedict]

It might not be too bad if done selectively? I agree that would be infeasible 
for each patch.

How many SCM modes do we have?

I worry more about developer burden. It sounds like we have a balancing act 
with SCM complexity versus upgrade complexity.

I think at the very least we should require that whatever you upgrade from 
should be in max SCM for that version, and the upgraded version should check it 
is brought up in the equivalent SCM for the new release until upgrade is 
complete. Hopefully this would prevent SCM from becoming a major extra 
dimension besides simply minor/major combinations.


> On 11 Dec 2024, at 12:43, Marcus Eriksson  wrote:
> 
> Staying slightly off topic - we'd also have to run upgrade tests for all 
> these upgrade combinations, including different storage compatibility mode 
> settings, that is going to be very expensive.
> 
> /Marcus
> 
>> On Wed, Dec 11, 2024 at 12:36:02PM GMT, Sam Tunnicliffe wrote:
>> Maybe this is not the right place to bring up practicalities, but the more 
>> upgrade paths we support the more complexity we take on. The ongoing issues 
>> mentioned in CASSANDRA-20118 are illustrative and the introduction of 
>> Storage Compatibility Mode adds further dimensions and operational 
>> complexity to any upgrade. At the very least, SCM needs decoupling from 
>> messaging versions as in its current form it prevents new versions from 
>> introducing any messaging format changes, regardless of any impact on 
>> storage formats.
>> 
>> * Should 5.1/6.0 continue to support CASSANDRA_4 SCM? (if we are going to 
>> support upgrades from 4.x then it has to).
>> * Do we have any plans for CASSANDRA_5 compatibility mode when upgrading to 
>> 5.1/6.0?
>> * If we want to continue to allow upgrades to jump multiple versions, do we 
>> allow any intermediate SCM setting? (i.e. go from 4.x to 6.x with SCM set to 
>> 5?)
>> 
>> Sorry for going off topic re: the actual number we give to the next release, 
>> I really don't feel strongly about 5.1 vs 6.0.
>> 
>> Thanks,
>> Sam
>> 
 On 11 Dec 2024, at 11:02, Rahul Singh (ANANT)  wrote:
>>> 
>>> +1 for calling it 6, even if just to bring up to people on 2.x,3.x that 
>>> they are on "ancient" code.
>>> 
>>> Sent via Superhuman iOS
>>> 
>>> 
 On Wed, Dec 11 2024 at 5:23 AM, Aleksey Yeshchenko  
 wrote:
>>> We don’t really practice canonic sermver, we never really have, and it’s 
>>> impossible to properly follow anyway.
>>> 
>>> Should be perfectly fine to bump to 6.0, so long as we don’t take the bump 
>>> as a license to break compatibility in a way that we wouldn’t have for 5.1.
>>> 
>>> 
 On 11 Dec 2024, at 00:11, Jon Haddad  wrote:
 
> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now 
> non-functioning.  And the cleaner code certainly helps navigate the code 
> base quicker.
 
 Sure - I was using that as an example, looking back in hindsight.  Like, 
 if today people could go from 2.1 -> 5.0 it would be cool.  Applying it to 
 the future, if someone could go from 4.1 to 7.0, that would be nice.
 
 I have no clue what that means for maintenance.  If it slowed development 
 time down, it becomes less useful.  
 
 Jon
 
 
 
 
 
 
 
 On Tue, Dec 10, 2024 at 3:57 PM Mick Semb Wever  wrote:
 
 
 I know a few teams on 2.2 that would *love* to be able to jump right to 
 5.0.  Once you fall far enough behind, upgrading to another version that's 
 already deprecated becomes paralyzing.  I don't expect 2.2 compatibility 
 btw, just using it as an example.  
 
 If it can be done, it would make a lot of folks very happy.
 
 If we could pull that off that would be great.  I would like to see it 
 happen first.
 A lot has already been cleaned in 4.0 that makes 3.x to 5.x now 
 non-functioning.  And the cleaner code certainly helps navigate the code 
 base quicker.
 
 (It was agreed to keep sstable format compatible indefinitely, but that's 
 about offline upgrading.  And even the bugs that exist around frozen 
 tuples/udts in the ma-md versions, I would suggest there's value in 
 raising the minimum compatibility to `me`.  This is an example that these 
 breakages still do happen, hopefully less over time, and _drawing a line 
 in the sand_ is a legit tactic to deal with them.)
 
 
 @Mick, you made me laugh, with your unique ability to agree disagreeably.  
  You might not care about marketing, but people pay more attention to 
 major version upgrades and "minor" ones.  Even though this can be in no 
 way be considered a minor change.  It doesn't matter what people "should" 
 do.  Major version bump is a signal to end users that this is a BIG DEAL.
 
 
 Yup!  A healthy community needs to be one where it's safe to present 
 diverse and/or unpopular points of view, without fear or concern of the 

Re: [DISCUSS] 5.1 should be 6.0

[Marcus Eriksson]

Staying slightly off topic - we'd also have to run upgrade tests for all these 
upgrade combinations, including different storage compatibility mode settings, 
that is going to be very expensive.

/Marcus

On Wed, Dec 11, 2024 at 12:36:02PM GMT, Sam Tunnicliffe wrote:
> Maybe this is not the right place to bring up practicalities, but the more 
> upgrade paths we support the more complexity we take on. The ongoing issues 
> mentioned in CASSANDRA-20118 are illustrative and the introduction of Storage 
> Compatibility Mode adds further dimensions and operational complexity to any 
> upgrade. At the very least, SCM needs decoupling from messaging versions as 
> in its current form it prevents new versions from introducing any messaging 
> format changes, regardless of any impact on storage formats. 
> 
> * Should 5.1/6.0 continue to support CASSANDRA_4 SCM? (if we are going to 
> support upgrades from 4.x then it has to).
> * Do we have any plans for CASSANDRA_5 compatibility mode when upgrading to 
> 5.1/6.0? 
> * If we want to continue to allow upgrades to jump multiple versions, do we 
> allow any intermediate SCM setting? (i.e. go from 4.x to 6.x with SCM set to 
> 5?) 
> 
> Sorry for going off topic re: the actual number we give to the next release, 
> I really don't feel strongly about 5.1 vs 6.0. 
> 
> Thanks,
> Sam
> 
> > On 11 Dec 2024, at 11:02, Rahul Singh (ANANT)  wrote:
> > 
> > +1 for calling it 6, even if just to bring up to people on 2.x,3.x that 
> > they are on "ancient" code. 
> > 
> > Sent via Superhuman iOS
> > 
> > 
> > On Wed, Dec 11 2024 at 5:23 AM, Aleksey Yeshchenko  
> > wrote: 
> > We don’t really practice canonic sermver, we never really have, and it’s 
> > impossible to properly follow anyway.
> > 
> > Should be perfectly fine to bump to 6.0, so long as we don’t take the bump 
> > as a license to break compatibility in a way that we wouldn’t have for 5.1.
> > 
> > 
> >> On 11 Dec 2024, at 00:11, Jon Haddad  wrote:
> >> 
> >> > A lot has already been cleaned in 4.0 that makes 3.x to 5.x now 
> >> > non-functioning.  And the cleaner code certainly helps navigate the code 
> >> > base quicker.
> >> 
> >> Sure - I was using that as an example, looking back in hindsight.  Like, 
> >> if today people could go from 2.1 -> 5.0 it would be cool.  Applying it to 
> >> the future, if someone could go from 4.1 to 7.0, that would be nice.
> >> 
> >> I have no clue what that means for maintenance.  If it slowed development 
> >> time down, it becomes less useful.  
> >> 
> >> Jon
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On Tue, Dec 10, 2024 at 3:57 PM Mick Semb Wever  wrote:
> >> 
> >> 
> >> I know a few teams on 2.2 that would *love* to be able to jump right to 
> >> 5.0.  Once you fall far enough behind, upgrading to another version that's 
> >> already deprecated becomes paralyzing.  I don't expect 2.2 compatibility 
> >> btw, just using it as an example.  
> >> 
> >> If it can be done, it would make a lot of folks very happy.
> >>  
> >> If we could pull that off that would be great.  I would like to see it 
> >> happen first.
> >> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now 
> >> non-functioning.  And the cleaner code certainly helps navigate the code 
> >> base quicker.
> >> 
> >> (It was agreed to keep sstable format compatible indefinitely, but that's 
> >> about offline upgrading.  And even the bugs that exist around frozen 
> >> tuples/udts in the ma-md versions, I would suggest there's value in 
> >> raising the minimum compatibility to `me`.  This is an example that these 
> >> breakages still do happen, hopefully less over time, and _drawing a line 
> >> in the sand_ is a legit tactic to deal with them.)
> >> 
> >> 
> >> @Mick, you made me laugh, with your unique ability to agree disagreeably.  
> >>  You might not care about marketing, but people pay more attention to 
> >> major version upgrades and "minor" ones.  Even though this can be in no 
> >> way be considered a minor change.  It doesn't matter what people "should" 
> >> do.  Major version bump is a signal to end users that this is a BIG DEAL.
> >> 
> >> 
> >> Yup!  A healthy community needs to be one where it's safe to present 
> >> diverse and/or unpopular points of view, without fear or concern of the 
> >> initial phase of discussion stagnating  :-) 
> >> Bikeshedding aside, my opinion is that the signal/feedback to the operator 
> >> about what they need to do is of more concrete value than the new features 
> >> list to the user. 
> >> 
> >> Aside, it is unfortunate that we associate minor semver version numbers as 
> >> "minor".  They are, after all, still referred to as major releases.  It is 
> >> just separate terminology between releases and semver that we are tripping 
> >> ourselves up over it, and our emphasis on "the number".   Ideally (imho) 
> >> it would be wonderful to keep semver private to us and operators, having 
> >> some other mechanism to signal user-facing/marketing, 

Re: [DISCUSS] 5.1 should be 6.0

[Sam Tunnicliffe]

Maybe this is not the right place to bring up practicalities, but the more 
upgrade paths we support the more complexity we take on. The ongoing issues 
mentioned in CASSANDRA-20118 are illustrative and the introduction of Storage 
Compatibility Mode adds further dimensions and operational complexity to any 
upgrade. At the very least, SCM needs decoupling from messaging versions as in 
its current form it prevents new versions from introducing any messaging format 
changes, regardless of any impact on storage formats. 

* Should 5.1/6.0 continue to support CASSANDRA_4 SCM? (if we are going to 
support upgrades from 4.x then it has to).
* Do we have any plans for CASSANDRA_5 compatibility mode when upgrading to 
5.1/6.0? 
* If we want to continue to allow upgrades to jump multiple versions, do we 
allow any intermediate SCM setting? (i.e. go from 4.x to 6.x with SCM set to 
5?) 

Sorry for going off topic re: the actual number we give to the next release, I 
really don't feel strongly about 5.1 vs 6.0. 

Thanks,
Sam

> On 11 Dec 2024, at 11:02, Rahul Singh (ANANT)  wrote:
> 
> +1 for calling it 6, even if just to bring up to people on 2.x,3.x that they 
> are on "ancient" code. 
> 
> Sent via Superhuman iOS
> 
> 
> On Wed, Dec 11 2024 at 5:23 AM, Aleksey Yeshchenko  wrote: 
> We don’t really practice canonic sermver, we never really have, and it’s 
> impossible to properly follow anyway.
> 
> Should be perfectly fine to bump to 6.0, so long as we don’t take the bump as 
> a license to break compatibility in a way that we wouldn’t have for 5.1.
> 
> 
>> On 11 Dec 2024, at 00:11, Jon Haddad  wrote:
>> 
>> > A lot has already been cleaned in 4.0 that makes 3.x to 5.x now 
>> > non-functioning.  And the cleaner code certainly helps navigate the code 
>> > base quicker.
>> 
>> Sure - I was using that as an example, looking back in hindsight.  Like, if 
>> today people could go from 2.1 -> 5.0 it would be cool.  Applying it to the 
>> future, if someone could go from 4.1 to 7.0, that would be nice.
>> 
>> I have no clue what that means for maintenance.  If it slowed development 
>> time down, it becomes less useful.  
>> 
>> Jon
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, Dec 10, 2024 at 3:57 PM Mick Semb Wever  wrote:
>> 
>> 
>> I know a few teams on 2.2 that would *love* to be able to jump right to 5.0. 
>>  Once you fall far enough behind, upgrading to another version that's 
>> already deprecated becomes paralyzing.  I don't expect 2.2 compatibility 
>> btw, just using it as an example.  
>> 
>> If it can be done, it would make a lot of folks very happy.
>>  
>> If we could pull that off that would be great.  I would like to see it 
>> happen first.
>> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now 
>> non-functioning.  And the cleaner code certainly helps navigate the code 
>> base quicker.
>> 
>> (It was agreed to keep sstable format compatible indefinitely, but that's 
>> about offline upgrading.  And even the bugs that exist around frozen 
>> tuples/udts in the ma-md versions, I would suggest there's value in raising 
>> the minimum compatibility to `me`.  This is an example that these breakages 
>> still do happen, hopefully less over time, and _drawing a line in the sand_ 
>> is a legit tactic to deal with them.)
>> 
>> 
>> @Mick, you made me laugh, with your unique ability to agree disagreeably.   
>> You might not care about marketing, but people pay more attention to major 
>> version upgrades and "minor" ones.  Even though this can be in no way be 
>> considered a minor change.  It doesn't matter what people "should" do.  
>> Major version bump is a signal to end users that this is a BIG DEAL.
>> 
>> 
>> Yup!  A healthy community needs to be one where it's safe to present diverse 
>> and/or unpopular points of view, without fear or concern of the initial 
>> phase of discussion stagnating  :-) 
>> Bikeshedding aside, my opinion is that the signal/feedback to the operator 
>> about what they need to do is of more concrete value than the new features 
>> list to the user. 
>> 
>> Aside, it is unfortunate that we associate minor semver version numbers as 
>> "minor".  They are, after all, still referred to as major releases.  It is 
>> just separate terminology between releases and semver that we are tripping 
>> ourselves up over it, and our emphasis on "the number".   Ideally (imho) it 
>> would be wonderful to keep semver private to us and operators, having some 
>> other mechanism to signal user-facing/marketing, like we do with sstable 
>> formats – but that's still always going to leak out in some way.
>> 
> 

Re: [DISCUSS] 5.1 should be 6.0

[Rahul Singh (ANANT)]

 +1 for calling it 6, even if just to bring up to people on 2.x,3.x that
they are on "ancient" code.

Sent via Superhuman iOS 


On Wed, Dec 11 2024 at 5:23 AM, Aleksey Yeshchenko 
wrote:

> We don’t really practice canonic sermver, we never really have, and it’s
> impossible to properly follow anyway.
>
> Should be perfectly fine to bump to 6.0, so long as we don’t take the bump
> as a license to break compatibility in a way that we wouldn’t have for 5.1.
>
>
> On 11 Dec 2024, at 00:11, Jon Haddad  wrote:
>
> > A lot has already been cleaned in 4.0 that makes 3.x to 5.x now
> non-functioning.  And the cleaner code certainly helps navigate the code
> base quicker.
>
> Sure - I was using that as an example, looking back in hindsight.  Like,
> if today people could go from 2.1 -> 5.0 it would be cool.  Applying it to
> the future, if someone could go from 4.1 to 7.0, that would be nice.
>
> I have no clue what that means for maintenance.  If it slowed development
> time down, it becomes less useful.
>
> Jon
>
>
>
>
>
>
>
> On Tue, Dec 10, 2024 at 3:57 PM Mick Semb Wever  wrote:
>
>>
>>
>> I know a few teams on 2.2 that would *love* to be able to jump right to
>>> 5.0.  Once you fall far enough behind, upgrading to another version that's
>>> already deprecated becomes paralyzing.  I don't expect 2.2 compatibility
>>> btw, just using it as an example.
>>>
>>> If it can be done, it would make a lot of folks very happy.
>>>
>>
>>
>> If we could pull that off that would be great.  I would like to see it
>> happen first.
>> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now
>> non-functioning.  And the cleaner code certainly helps navigate the code
>> base quicker.
>>
>> (It was agreed to keep sstable format compatible indefinitely, but that's
>> about offline upgrading.  And even the bugs that exist around frozen
>> tuples/udts in the ma-md versions, I would suggest there's value in raising
>> the minimum compatibility to `me`.  This is an example that these breakages
>> still do happen, hopefully less over time, and _drawing a line in the sand_
>> is a legit tactic to deal with them.)
>>
>>
>> @Mick, you made me laugh, with your unique ability to agree
>>> disagreeably.   You might not care about marketing, but people pay more
>>> attention to major version upgrades and "minor" ones.  Even though this can
>>> be in no way be considered a minor change.  It doesn't matter what people
>>> "should" do.  Major version bump is a signal to end users that this is a
>>> BIG DEAL.
>>>
>>
>>
>> Yup!  A healthy community needs to be one where it's safe to present
>> diverse and/or unpopular points of view, without fear or concern of the
>> initial phase of discussion stagnating  :-)
>> Bikeshedding aside, my opinion is that the signal/feedback to the
>> operator about what they need to do is of more concrete value than the new
>> features list to the user.
>>
>> Aside, it is unfortunate that we associate minor semver version numbers
>> as "minor".  They are, after all, still referred to as major releases.  It
>> is just separate terminology between releases and semver that we are
>> tripping ourselves up over it, and our emphasis on "the number".   Ideally
>> (imho) it would be wonderful to keep semver private to us and operators,
>> having some other mechanism to signal user-facing/marketing, like we do
>> with sstable formats – but that's still always going to leak out in some
>> way.
>>
>>
>

Re: [DISCUSS] 5.1 should be 6.0

[Aleksey Yeshchenko]

We don’t really practice canonic sermver, we never really have, and it’s 
impossible to properly follow anyway.

Should be perfectly fine to bump to 6.0, so long as we don’t take the bump as a 
license to break compatibility in a way that we wouldn’t have for 5.1.


> On 11 Dec 2024, at 00:11, Jon Haddad  wrote:
> 
> > A lot has already been cleaned in 4.0 that makes 3.x to 5.x now 
> > non-functioning.  And the cleaner code certainly helps navigate the code 
> > base quicker.
> 
> Sure - I was using that as an example, looking back in hindsight.  Like, if 
> today people could go from 2.1 -> 5.0 it would be cool.  Applying it to the 
> future, if someone could go from 4.1 to 7.0, that would be nice.
> 
> I have no clue what that means for maintenance.  If it slowed development 
> time down, it becomes less useful. 
> 
> Jon
> 
> 
> 
> 
> 
> 
> 
> On Tue, Dec 10, 2024 at 3:57 PM Mick Semb Wever  > wrote:
>> 
>> 
>>> I know a few teams on 2.2 that would *love* to be able to jump right to 
>>> 5.0.  Once you fall far enough behind, upgrading to another version that's 
>>> already deprecated becomes paralyzing.  I don't expect 2.2 compatibility 
>>> btw, just using it as an example. 
>>> 
>>> If it can be done, it would make a lot of folks very happy.
>>  
>> 
>> If we could pull that off that would be great.  I would like to see it 
>> happen first.
>> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now 
>> non-functioning.  And the cleaner code certainly helps navigate the code 
>> base quicker.
>> 
>> (It was agreed to keep sstable format compatible indefinitely, but that's 
>> about offline upgrading.  And even the bugs that exist around frozen 
>> tuples/udts in the ma-md versions, I would suggest there's value in raising 
>> the minimum compatibility to `me`.  This is an example that these breakages 
>> still do happen, hopefully less over time, and _drawing a line in the sand_ 
>> is a legit tactic to deal with them.)
>> 
>> 
>>> @Mick, you made me laugh, with your unique ability to agree disagreeably.   
>>> You might not care about marketing, but people pay more attention to major 
>>> version upgrades and "minor" ones.  Even though this can be in no way be 
>>> considered a minor change.  It doesn't matter what people "should" do.  
>>> Major version bump is a signal to end users that this is a BIG DEAL.
>> 
>> 
>> 
>> Yup!  A healthy community needs to be one where it's safe to present diverse 
>> and/or unpopular points of view, without fear or concern of the initial 
>> phase of discussion stagnating  :-) 
>> Bikeshedding aside, my opinion is that the signal/feedback to the operator 
>> about what they need to do is of more concrete value than the new features 
>> list to the user. 
>> 
>> Aside, it is unfortunate that we associate minor semver version numbers as 
>> "minor".  They are, after all, still referred to as major releases.  It is 
>> just separate terminology between releases and semver that we are tripping 
>> ourselves up over it, and our emphasis on "the number".   Ideally (imho) it 
>> would be wonderful to keep semver private to us and operators, having some 
>> other mechanism to signal user-facing/marketing, like we do with sstable 
>> formats – but that's still always going to leak out in some way.
>> 

Re: [DISCUSS] 5.1 should be 6.0

[Jon Haddad]

> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now
non-functioning.  And the cleaner code certainly helps navigate the code
base quicker.

Sure - I was using that as an example, looking back in hindsight.  Like, if
today people could go from 2.1 -> 5.0 it would be cool.  Applying it to the
future, if someone could go from 4.1 to 7.0, that would be nice.

I have no clue what that means for maintenance.  If it slowed development
time down, it becomes less useful.

Jon







On Tue, Dec 10, 2024 at 3:57 PM Mick Semb Wever  wrote:

>
>
> I know a few teams on 2.2 that would *love* to be able to jump right to
>> 5.0.  Once you fall far enough behind, upgrading to another version that's
>> already deprecated becomes paralyzing.  I don't expect 2.2 compatibility
>> btw, just using it as an example.
>>
>> If it can be done, it would make a lot of folks very happy.
>>
>
>
> If we could pull that off that would be great.  I would like to see it
> happen first.
> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now
> non-functioning.  And the cleaner code certainly helps navigate the code
> base quicker.
>
> (It was agreed to keep sstable format compatible indefinitely, but that's
> about offline upgrading.  And even the bugs that exist around frozen
> tuples/udts in the ma-md versions, I would suggest there's value in raising
> the minimum compatibility to `me`.  This is an example that these breakages
> still do happen, hopefully less over time, and _drawing a line in the sand_
> is a legit tactic to deal with them.)
>
>
> @Mick, you made me laugh, with your unique ability to agree
>> disagreeably.   You might not care about marketing, but people pay more
>> attention to major version upgrades and "minor" ones.  Even though this can
>> be in no way be considered a minor change.  It doesn't matter what people
>> "should" do.  Major version bump is a signal to end users that this is a
>> BIG DEAL.
>>
>
>
> Yup!  A healthy community needs to be one where it's safe to present
> diverse and/or unpopular points of view, without fear or concern of the
> initial phase of discussion stagnating  :-)
> Bikeshedding aside, my opinion is that the signal/feedback to the operator
> about what they need to do is of more concrete value than the new features
> list to the user.
>
> Aside, it is unfortunate that we associate minor semver version numbers as
> "minor".  They are, after all, still referred to as major releases.  It is
> just separate terminology between releases and semver that we are tripping
> ourselves up over it, and our emphasis on "the number".   Ideally (imho) it
> would be wonderful to keep semver private to us and operators, having some
> other mechanism to signal user-facing/marketing, like we do with sstable
> formats – but that's still always going to leak out in some way.
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

I know a few teams on 2.2 that would *love* to be able to jump right to
> 5.0.  Once you fall far enough behind, upgrading to another version that's
> already deprecated becomes paralyzing.  I don't expect 2.2 compatibility
> btw, just using it as an example.
>
> If it can be done, it would make a lot of folks very happy.
>


If we could pull that off that would be great.  I would like to see it
happen first.
A lot has already been cleaned in 4.0 that makes 3.x to 5.x now
non-functioning.  And the cleaner code certainly helps navigate the code
base quicker.

(It was agreed to keep sstable format compatible indefinitely, but that's
about offline upgrading.  And even the bugs that exist around frozen
tuples/udts in the ma-md versions, I would suggest there's value in raising
the minimum compatibility to `me`.  This is an example that these breakages
still do happen, hopefully less over time, and _drawing a line in the sand_
is a legit tactic to deal with them.)


@Mick, you made me laugh, with your unique ability to agree disagreeably.
> You might not care about marketing, but people pay more attention to major
> version upgrades and "minor" ones.  Even though this can be in no way be
> considered a minor change.  It doesn't matter what people "should" do.
> Major version bump is a signal to end users that this is a BIG DEAL.
>


Yup!  A healthy community needs to be one where it's safe to present
diverse and/or unpopular points of view, without fear or concern of the
initial phase of discussion stagnating  :-)
Bikeshedding aside, my opinion is that the signal/feedback to the operator
about what they need to do is of more concrete value than the new features
list to the user.

Aside, it is unfortunate that we associate minor semver version numbers as
"minor".  They are, after all, still referred to as major releases.  It is
just separate terminology between releases and semver that we are tripping
ourselves up over it, and our emphasis on "the number".   Ideally (imho) it
would be wonderful to keep semver private to us and operators, having some
other mechanism to signal user-facing/marketing, like we do with sstable
formats – but that's still always going to leak out in some way.

Re: [DISCUSS] 5.1 should be 6.0

[Benedict]

I have to agree. Harder upgrades are simpler for users? No chance.I like Jeremiah’s proposal, but would also be happy with a less rigid “we support as many versions as we can without it becoming a burden” - which for some versions might be one minor/major, and for others might be three or more.On 10 Dec 2024, at 22:10, Jon Haddad  wrote:I know a few teams on 2.2 that would *love* to be able to jump right to 5.0.  Once you fall far enough behind, upgrading to another version that's already deprecated becomes paralyzing.  I don't expect 2.2 compatibility btw, just using it as an example.  If it can be done, it would make a lot of folks very happy.@Mick, you made me laugh, with your unique ability to agree disagreeably.   You might not care about marketing, but people pay more attention to major version upgrades and "minor" ones.  Even though this can be in no way be considered a minor change.  It doesn't matter what people "should" do.  Major version bump is a signal to end users that this is a BIG DEAL.JonOn Tue, Dec 10, 2024 at 1:58 PM Jeremiah Jordan  wrote:
I think the simplest upgrade path is actually “you can upgrade from any currently ’supported’ version to this new one”.  So for 5.1/6.0 that would be 4.0/4.1/5.0.  That has always been my preferred support model for upgrades.-Jeremiah


On Dec 10, 2024 at 3:45:52 PM, Mick Semb Wever  wrote:

I would very much rather keep our upgrade paths simple and intuitive:You can only upgrade between adjacent major versions.This does catch users, and keeping it simple has helped a lot.I find it helps internally working on the code too, with a focus on stability for online upgrades, which does quickly become messy.I'm open to the suggestion that TCM changes enough that it warrants it, and if we're ok imposing onto the user that this change means they have to upgrade from 4.x to 5.0 before 6.0.  Major upgrades are not trivial, we see enterprises often need 6 months.I would much rather use the introduction of Java21 and the removal of Java11 as the compatibility change that warrants the bump to 6.0.  I haven't thought about Python here, I don't think it applies as it's not a server-side change that we recommend the operator avoid making at the same time as an upgrade.On the bikeshedding front: I'm against major version bumps for feature marketing reasons.  A leading number is not required to sell features as significant as Accord and TCM.  It's a personal opinion, but it just feels desperate and lacking in confidence for a technology as established as C*. Let the work speak for itself.  On Wed, 11 Dec 2024 at 07:16, Caleb Rackliffe  wrote:I don't care what we call it as long as 4.1 -> 5.1/6.0 upgrades are possible.On Tue, Dec 10, 2024 at 1:28 PM David Capwell  wrote:Given our version support… if we do make this change does this imply users must do the following to get to 6.0?4.x upgrade to 5.05.0 upgrade to 6.0So no 4.x to 6.0?  Given that this is 5.1 atm we are expected to support 4.x to 5.1 upgrades, but switching to 6.0 that isn’t true based off our documentationOn Dec 10, 2024, at 11:00 AM, Josh McKenzie  wrote:This is another topic we basically revisit afresh every time :) I think it’s fine to bump for marketing or vibe reasons, I would support it. I don’t think we need to confect some weak semverish justification.Vibes ftw.Lets see if any strong contradicting opinions pop up on here in the next few days; if not I'll draft up a revision to the wiki. Taking it on a case-by-case release basis w/a respect for vibes sounds perfect to me.On Tue, Dec 10, 2024, at 1:37 PM, Patrick McFadin wrote:I was waiting for this discussion to happen again. :pWhat you call marketing, I call end-user communication. I'll leavethis open question, but what do we want to communicate to the userbase, and how should they approach this new feature set?PatrickOn Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith wrote:>> This is another topic we basically revisit afresh every time :)>> I think it’s fine to bump for marketing or vibe reasons, I would support it. I don’t think we need to confect some weak semverish justification.>> > On 10 Dec 2024, at 13:01, Brandon Williams  wrote:> >> > Even if TCM is api-compatible, it will change how operators run> > Cassandra in a significant way (like, different procedures from every> > previous version.)  I think that justifies a major.> >> > Kind Regards,> > Brandon> >> > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:> >>> >> You’ve added a ton of API surface to transaction behavior and cluster management. The TCM may or may not be strictly breaking, but they’re fundamentally very very different, so even with semver as the only standard, I think you can justify a major.> >>> >> But also, let’s just acknowledge that marketing is a thing and bump the major 

Re: [DISCUSS] 5.1 should be 6.0

[Jon Haddad]

I know a few teams on 2.2 that would *love* to be able to jump right to
5.0.  Once you fall far enough behind, upgrading to another version that's
already deprecated becomes paralyzing.  I don't expect 2.2 compatibility
btw, just using it as an example.

If it can be done, it would make a lot of folks very happy.

@Mick, you made me laugh, with your unique ability to agree disagreeably.
You might not care about marketing, but people pay more attention to major
version upgrades and "minor" ones.  Even though this can be in no way be
considered a minor change.  It doesn't matter what people "should" do.
Major version bump is a signal to end users that this is a BIG DEAL.

Jon



On Tue, Dec 10, 2024 at 1:58 PM Jeremiah Jordan 
wrote:

> I think the simplest upgrade path is actually “you can upgrade from any
> currently ’supported’ version to this new one”.  So for 5.1/6.0 that would
> be 4.0/4.1/5.0.  That has always been my preferred support model for
> upgrades.
>
> -Jeremiah
>
> On Dec 10, 2024 at 3:45:52 PM, Mick Semb Wever  wrote:
>
>>
>> I would very much rather keep our upgrade paths simple and intuitive:
>> You can only upgrade between adjacent major versions.
>>
>> This does catch users, and keeping it simple has helped a lot.
>> I find it helps internally working on the code too, with a focus on
>> stability for online upgrades, which does quickly become messy.
>>
>> I'm open to the suggestion that TCM changes enough that it warrants it,
>> and if we're ok imposing onto the user that this change means they have to
>> upgrade from 4.x to 5.0 before 6.0.  Major upgrades are not trivial, we see
>> enterprises often need 6 months.
>>
>> I would much rather use the introduction of Java21 and the removal of
>> Java11 as the compatibility change that warrants the bump to 6.0.  I
>> haven't thought about Python here, I don't think it applies as it's not a
>> server-side change that we recommend the operator avoid making at the same
>> time as an upgrade.
>>
>> On the bikeshedding front: I'm against major version bumps for feature
>> marketing reasons.  A leading number is not required to sell features as
>> significant as Accord and TCM.  It's a personal opinion, but it just feels
>> desperate and lacking in confidence for a technology as established as C*.
>> Let the work speak for itself.
>>
>>
>>
>> On Wed, 11 Dec 2024 at 07:16, Caleb Rackliffe 
>> wrote:
>>
>>> I don't care what we call it as long as 4.1 -> 5.1/6.0 upgrades are
>>> possible.
>>>
>>> On Tue, Dec 10, 2024 at 1:28 PM David Capwell 
>>> wrote:
>>>
 Given our version support… if we do make this change does this imply
 users must do the following to get to 6.0?

 4.x upgrade to 5.0
 5.0 upgrade to 6.0

 So no 4.x to 6.0?  Given that this is 5.1 atm we are expected to
 support 4.x to 5.1 upgrades, but switching to 6.0 that isn’t true based off
 our documentation

 On Dec 10, 2024, at 11:00 AM, Josh McKenzie 
 wrote:

 This is another topic we basically revisit afresh every time :)

 I think it’s fine to bump for marketing or vibe reasons, I would
 support it. I don’t think we need to confect some weak semverish
 justification.

 Vibes ftw.

 Lets see if any strong contradicting opinions pop up on here in the
 next few days; if not I'll draft up a revision to the wiki. Taking it on a
 case-by-case release basis w/a respect for vibes sounds perfect to me.

 On Tue, Dec 10, 2024, at 1:37 PM, Patrick McFadin wrote:

 I was waiting for this discussion to happen again. :p

 What you call marketing, I call end-user communication. I'll leave
 this open question, but what do we want to communicate to the user
 base, and how should they approach this new feature set?

 Patrick

 On Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith
  wrote:
 >
 > This is another topic we basically revisit afresh every time :)
 >
 > I think it’s fine to bump for marketing or vibe reasons, I would
 support it. I don’t think we need to confect some weak semverish
 justification.
 >
 > > On 10 Dec 2024, at 13:01, Brandon Williams 
 wrote:
 > >
 > > Even if TCM is api-compatible, it will change how operators run
 > > Cassandra in a significant way (like, different procedures from
 every
 > > previous version.)  I think that justifies a major.
 > >
 > > Kind Regards,
 > > Brandon
 > >
 > > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa 
 wrote:
 > >>
 > >> You’ve added a ton of API surface to transaction behavior and
 cluster management. The TCM may or may not be strictly breaking, but
 they’re fundamentally very very different, so even with semver as the only
 standard, I think you can justify a major.
 > >>
 > >> But also, let’s just acknowledge that marketing is a thing and
 bump the major to acknowledge the huge, 

Re: [DISCUSS] 5.1 should be 6.0

[Jeremiah Jordan]

 I think the simplest upgrade path is actually “you can upgrade from any
currently ’supported’ version to this new one”.  So for 5.1/6.0 that would
be 4.0/4.1/5.0.  That has always been my preferred support model for
upgrades.

-Jeremiah

On Dec 10, 2024 at 3:45:52 PM, Mick Semb Wever  wrote:

>
> I would very much rather keep our upgrade paths simple and intuitive:
> You can only upgrade between adjacent major versions.
>
> This does catch users, and keeping it simple has helped a lot.
> I find it helps internally working on the code too, with a focus on
> stability for online upgrades, which does quickly become messy.
>
> I'm open to the suggestion that TCM changes enough that it warrants it,
> and if we're ok imposing onto the user that this change means they have to
> upgrade from 4.x to 5.0 before 6.0.  Major upgrades are not trivial, we see
> enterprises often need 6 months.
>
> I would much rather use the introduction of Java21 and the removal of
> Java11 as the compatibility change that warrants the bump to 6.0.  I
> haven't thought about Python here, I don't think it applies as it's not a
> server-side change that we recommend the operator avoid making at the same
> time as an upgrade.
>
> On the bikeshedding front: I'm against major version bumps for feature
> marketing reasons.  A leading number is not required to sell features as
> significant as Accord and TCM.  It's a personal opinion, but it just feels
> desperate and lacking in confidence for a technology as established as C*.
> Let the work speak for itself.
>
>
>
> On Wed, 11 Dec 2024 at 07:16, Caleb Rackliffe 
> wrote:
>
>> I don't care what we call it as long as 4.1 -> 5.1/6.0 upgrades are
>> possible.
>>
>> On Tue, Dec 10, 2024 at 1:28 PM David Capwell  wrote:
>>
>>> Given our version support… if we do make this change does this imply
>>> users must do the following to get to 6.0?
>>>
>>> 4.x upgrade to 5.0
>>> 5.0 upgrade to 6.0
>>>
>>> So no 4.x to 6.0?  Given that this is 5.1 atm we are expected to support
>>> 4.x to 5.1 upgrades, but switching to 6.0 that isn’t true based off our
>>> documentation
>>>
>>> On Dec 10, 2024, at 11:00 AM, Josh McKenzie 
>>> wrote:
>>>
>>> This is another topic we basically revisit afresh every time :)
>>>
>>> I think it’s fine to bump for marketing or vibe reasons, I would support
>>> it. I don’t think we need to confect some weak semverish justification.
>>>
>>> Vibes ftw.
>>>
>>> Lets see if any strong contradicting opinions pop up on here in the next
>>> few days; if not I'll draft up a revision to the wiki. Taking it on a
>>> case-by-case release basis w/a respect for vibes sounds perfect to me.
>>>
>>> On Tue, Dec 10, 2024, at 1:37 PM, Patrick McFadin wrote:
>>>
>>> I was waiting for this discussion to happen again. :p
>>>
>>> What you call marketing, I call end-user communication. I'll leave
>>> this open question, but what do we want to communicate to the user
>>> base, and how should they approach this new feature set?
>>>
>>> Patrick
>>>
>>> On Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith
>>>  wrote:
>>> >
>>> > This is another topic we basically revisit afresh every time :)
>>> >
>>> > I think it’s fine to bump for marketing or vibe reasons, I would
>>> support it. I don’t think we need to confect some weak semverish
>>> justification.
>>> >
>>> > > On 10 Dec 2024, at 13:01, Brandon Williams  wrote:
>>> > >
>>> > > Even if TCM is api-compatible, it will change how operators run
>>> > > Cassandra in a significant way (like, different procedures from every
>>> > > previous version.)  I think that justifies a major.
>>> > >
>>> > > Kind Regards,
>>> > > Brandon
>>> > >
>>> > > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa 
>>> wrote:
>>> > >>
>>> > >> You’ve added a ton of API surface to transaction behavior and
>>> cluster management. The TCM may or may not be strictly breaking, but
>>> they’re fundamentally very very different, so even with semver as the only
>>> standard, I think you can justify a major.
>>> > >>
>>> > >> But also, let’s just acknowledge that marketing is a thing and bump
>>> the major to acknowledge the huge, massive, database-changing features,
>>> even if they’re not meant to be disruptive.
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Dec 10, 2024, at 9:46 AM, Josh McKenzie 
>>> wrote:
>>> > >>
>>> > >> Currently we reserve MAJOR in semver changes for API breaking only:
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting
>>> :
>>> > >>
>>> > >> That's consistent w/semver itself: link:
>>> > >>
>>> > >> Given a version number MAJOR.MINOR.PATCH, increment the:
>>> > >>
>>> > >> MAJOR version when you make incompatible API changes
>>> > >> MINOR version when you add functionality in a backward compatible
>>> manner
>>> > >> PATCH version when you make backward compatible bug fixes
>>> > >>
>>> > >>
>>> > >> So absolute literal "correctness" of what we're doing aside, our
>>> version numbers 

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

I would very much rather keep our upgrade paths simple and intuitive:
You can only upgrade between adjacent major versions.

This does catch users, and keeping it simple has helped a lot.
I find it helps internally working on the code too, with a focus on
stability for online upgrades, which does quickly become messy.

I'm open to the suggestion that TCM changes enough that it warrants it, and
if we're ok imposing onto the user that this change means they have to
upgrade from 4.x to 5.0 before 6.0.  Major upgrades are not trivial, we see
enterprises often need 6 months.

I would much rather use the introduction of Java21 and the removal of
Java11 as the compatibility change that warrants the bump to 6.0.  I
haven't thought about Python here, I don't think it applies as it's not a
server-side change that we recommend the operator avoid making at the same
time as an upgrade.

On the bikeshedding front: I'm against major version bumps for feature
marketing reasons.  A leading number is not required to sell features as
significant as Accord and TCM.  It's a personal opinion, but it just feels
desperate and lacking in confidence for a technology as established as C*.
Let the work speak for itself.



On Wed, 11 Dec 2024 at 07:16, Caleb Rackliffe 
wrote:

> I don't care what we call it as long as 4.1 -> 5.1/6.0 upgrades are
> possible.
>
> On Tue, Dec 10, 2024 at 1:28 PM David Capwell  wrote:
>
>> Given our version support… if we do make this change does this imply
>> users must do the following to get to 6.0?
>>
>> 4.x upgrade to 5.0
>> 5.0 upgrade to 6.0
>>
>> So no 4.x to 6.0?  Given that this is 5.1 atm we are expected to support
>> 4.x to 5.1 upgrades, but switching to 6.0 that isn’t true based off our
>> documentation
>>
>> On Dec 10, 2024, at 11:00 AM, Josh McKenzie  wrote:
>>
>> This is another topic we basically revisit afresh every time :)
>>
>> I think it’s fine to bump for marketing or vibe reasons, I would support
>> it. I don’t think we need to confect some weak semverish justification.
>>
>> Vibes ftw.
>>
>> Lets see if any strong contradicting opinions pop up on here in the next
>> few days; if not I'll draft up a revision to the wiki. Taking it on a
>> case-by-case release basis w/a respect for vibes sounds perfect to me.
>>
>> On Tue, Dec 10, 2024, at 1:37 PM, Patrick McFadin wrote:
>>
>> I was waiting for this discussion to happen again. :p
>>
>> What you call marketing, I call end-user communication. I'll leave
>> this open question, but what do we want to communicate to the user
>> base, and how should they approach this new feature set?
>>
>> Patrick
>>
>> On Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith
>>  wrote:
>> >
>> > This is another topic we basically revisit afresh every time :)
>> >
>> > I think it’s fine to bump for marketing or vibe reasons, I would
>> support it. I don’t think we need to confect some weak semverish
>> justification.
>> >
>> > > On 10 Dec 2024, at 13:01, Brandon Williams  wrote:
>> > >
>> > > Even if TCM is api-compatible, it will change how operators run
>> > > Cassandra in a significant way (like, different procedures from every
>> > > previous version.)  I think that justifies a major.
>> > >
>> > > Kind Regards,
>> > > Brandon
>> > >
>> > > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:
>> > >>
>> > >> You’ve added a ton of API surface to transaction behavior and
>> cluster management. The TCM may or may not be strictly breaking, but
>> they’re fundamentally very very different, so even with semver as the only
>> standard, I think you can justify a major.
>> > >>
>> > >> But also, let’s just acknowledge that marketing is a thing and bump
>> the major to acknowledge the huge, massive, database-changing features,
>> even if they’re not meant to be disruptive.
>> > >>
>> > >>
>> > >>
>> > >> On Dec 10, 2024, at 9:46 AM, Josh McKenzie 
>> wrote:
>> > >>
>> > >> Currently we reserve MAJOR in semver changes for API breaking only:
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting
>> :
>> > >>
>> > >> That's consistent w/semver itself: link:
>> > >>
>> > >> Given a version number MAJOR.MINOR.PATCH, increment the:
>> > >>
>> > >> MAJOR version when you make incompatible API changes
>> > >> MINOR version when you add functionality in a backward compatible
>> manner
>> > >> PATCH version when you make backward compatible bug fixes
>> > >>
>> > >>
>> > >> So absolute literal "correctness" of what we're doing aside, our
>> version numbers mean something to us as a dev community but also mean
>> something to Cassandra users. I'm not confident they mean the same thing to
>> each constituency. I'm also not comfortable with us prioritizing our own
>> version number needs over that of our users, should they differ in meaning.
>> > >>
>> > >> Does anybody have insight into how other well known widely adopted
>> projects do things we might be able to learn from? I generally only 

Re: [DISCUSS] 5.1 should be 6.0

[Brad]

Usually, a major release would bump the Java and Python supported versions.
Both Java and Python are on well-published and faster release cycles.


On Tue, Dec 10, 2024 at 3:40 PM Paulo Motta  wrote:

> I share this sentiment. Outside of marketing and API compatibility
> considerations, I think the changes are significant enough to warrant a
> major version bump, since it represents a new generation of the database.
>
> On Tue, Dec 10, 2024 at 1:02 PM Brandon Williams  wrote:
>
>> Even if TCM is api-compatible, it will change how operators run
>> Cassandra in a significant way (like, different procedures from every
>> previous version.)  I think that justifies a major.
>>
>> Kind Regards,
>> Brandon
>>
>> On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:
>> >
>> > You’ve added a ton of API surface to transaction behavior and cluster
>> management. The TCM may or may not be strictly breaking, but they’re
>> fundamentally very very different, so even with semver as the only
>> standard, I think you can justify a major.
>> >
>> > But also, let’s just acknowledge that marketing is a thing and bump the
>> major to acknowledge the huge, massive, database-changing features, even if
>> they’re not meant to be disruptive.
>> >
>> >
>> >
>> > On Dec 10, 2024, at 9:46 AM, Josh McKenzie 
>> wrote:
>> >
>> > Currently we reserve MAJOR in semver changes for API breaking only:
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting
>> :
>> >
>> > That's consistent w/semver itself: link:
>> >
>> > Given a version number MAJOR.MINOR.PATCH, increment the:
>> >
>> > MAJOR version when you make incompatible API changes
>> > MINOR version when you add functionality in a backward compatible manner
>> > PATCH version when you make backward compatible bug fixes
>> >
>> >
>> > So absolute literal "correctness" of what we're doing aside, our
>> version numbers mean something to us as a dev community but also mean
>> something to Cassandra users. I'm not confident they mean the same thing to
>> each constituency. I'm also not comfortable with us prioritizing our own
>> version number needs over that of our users, should they differ in meaning.
>> >
>> > Does anybody have insight into how other well known widely adopted
>> projects do things we might be able to learn from? I generally only think
>> about this topic when a discussion like this comes up on our dev list so
>> don't have much insight to bring to the discussion.
>> >
>> > On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
>> >
>> > The question is if we are signaling compatibility or purely marketing
>> with the release number.
>> > We dropped compatibility with a few things in 5.0, which was the reason
>> for the .0 rather than 4.2.  I don’t know if we are breaking any
>> compatibility with current trunk?  Though maybe some of the TCM stuff could
>> be considered that.
>> > If we are purely going for marketing value, then yes, I agree
>> TCM+Accord would be 6.0 worthy.
>> >
>> > -Jeremiah
>> >
>> > On Dec 10, 2024 at 10:48:21 AM, Jon Haddad 
>> wrote:
>> >
>> > Keeping this short.  I'm not sure why we're calling the next release
>> 5.1.  TCM and Accord are a massive thing.  Other .1 / .2 releases were the
>> .0 with some smaller things added.  Imo this is a huge step forward, as big
>> as 5.0 was, so we should call it 6.0.
>> >
>> >
>>
>

Re: [DISCUSS] 5.1 should be 6.0

[Benedict]

The only thing the version numbers communicate for upgrades is a minimum guarantee. Just as we allowed 3.x to 5.0 we can and should allow 4.x to 6.0. If anything I would like to see us move towards a norm of supporting upgrade across more milestone releases as standard.On 10 Dec 2024, at 20:16, Caleb Rackliffe  wrote:I don't care what we call it as long as 4.1 -> 5.1/6.0 upgrades are possible.On Tue, Dec 10, 2024 at 1:28 PM David Capwell  wrote:Given our version support… if we do make this change does this imply users must do the following to get to 6.0?4.x upgrade to 5.05.0 upgrade to 6.0So no 4.x to 6.0?  Given that this is 5.1 atm we are expected to support 4.x to 5.1 upgrades, but switching to 6.0 that isn’t true based off our documentationOn Dec 10, 2024, at 11:00 AM, Josh McKenzie  wrote:This is another topic we basically revisit afresh every time :) I think it’s fine to bump for marketing or vibe reasons, I would support it. I don’t think we need to confect some weak semverish justification.Vibes ftw.Lets see if any strong contradicting opinions pop up on here in the next few days; if not I'll draft up a revision to the wiki. Taking it on a case-by-case release basis w/a respect for vibes sounds perfect to me.On Tue, Dec 10, 2024, at 1:37 PM, Patrick McFadin wrote:I was waiting for this discussion to happen again. :pWhat you call marketing, I call end-user communication. I'll leavethis open question, but what do we want to communicate to the userbase, and how should they approach this new feature set?PatrickOn Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith wrote:>> This is another topic we basically revisit afresh every time :)>> I think it’s fine to bump for marketing or vibe reasons, I would support it. I don’t think we need to confect some weak semverish justification.>> > On 10 Dec 2024, at 13:01, Brandon Williams  wrote:> >> > Even if TCM is api-compatible, it will change how operators run> > Cassandra in a significant way (like, different procedures from every> > previous version.)  I think that justifies a major.> >> > Kind Regards,> > Brandon> >> > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:> >>> >> You’ve added a ton of API surface to transaction behavior and cluster management. The TCM may or may not be strictly breaking, but they’re fundamentally very very different, so even with semver as the only standard, I think you can justify a major.> >>> >> But also, let’s just acknowledge that marketing is a thing and bump the major to acknowledge the huge, massive, database-changing features, even if they’re not meant to be disruptive.> >>> >>> >>> >> On Dec 10, 2024, at 9:46 AM, Josh McKenzie  wrote:> >>> >> Currently we reserve MAJOR in semver changes for API breaking only: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting:> >>> >> That's consistent w/semver itself: link:> >>> >> Given a version number MAJOR.MINOR.PATCH, increment the:> >>> >> MAJOR version when you make incompatible API changes> >> MINOR version when you add functionality in a backward compatible manner> >> PATCH version when you make backward compatible bug fixes> >>> >>> >> So absolute literal "correctness" of what we're doing aside, our version numbers mean something to us as a dev community but also mean something to Cassandra users. I'm not confident they mean the same thing to each constituency. I'm also not comfortable with us prioritizing our own version number needs over that of our users, should they differ in meaning.> >>> >> Does anybody have insight into how other well known widely adopted projects do things we might be able to learn from? I generally only think about this topic when a discussion like this comes up on our dev list so don't have much insight to bring to the discussion.> >>> >> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:> >>> >> The question is if we are signaling compatibility or purely marketing with the release number.> >> We dropped compatibility with a few things in 5.0, which was the reason for the .0 rather than 4.2.  I don’t know if we are breaking any compatibility with current trunk?  Though maybe some of the TCM stuff could be considered that.> >> If we are purely going for marketing value, then yes, I agree TCM+Accord would be 6.0 worthy.> >>> >> -Jeremiah> >>> >> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad  wrote:> >>> >> Keeping this short.  I'm not sure why we're calling the next release 5.1.  TCM and Accord are a massive thing.  Other .1 / .2 releases were the .0 with some smaller things added.  Imo this is a huge step forward, as big as 5.0 was, so we should call it 6.0.> >>> >>>

Re: [DISCUSS] 5.1 should be 6.0

[Paulo Motta]

I share this sentiment. Outside of marketing and API compatibility
considerations, I think the changes are significant enough to warrant a
major version bump, since it represents a new generation of the database.

On Tue, Dec 10, 2024 at 1:02 PM Brandon Williams  wrote:

> Even if TCM is api-compatible, it will change how operators run
> Cassandra in a significant way (like, different procedures from every
> previous version.)  I think that justifies a major.
>
> Kind Regards,
> Brandon
>
> On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:
> >
> > You’ve added a ton of API surface to transaction behavior and cluster
> management. The TCM may or may not be strictly breaking, but they’re
> fundamentally very very different, so even with semver as the only
> standard, I think you can justify a major.
> >
> > But also, let’s just acknowledge that marketing is a thing and bump the
> major to acknowledge the huge, massive, database-changing features, even if
> they’re not meant to be disruptive.
> >
> >
> >
> > On Dec 10, 2024, at 9:46 AM, Josh McKenzie  wrote:
> >
> > Currently we reserve MAJOR in semver changes for API breaking only:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting
> :
> >
> > That's consistent w/semver itself: link:
> >
> > Given a version number MAJOR.MINOR.PATCH, increment the:
> >
> > MAJOR version when you make incompatible API changes
> > MINOR version when you add functionality in a backward compatible manner
> > PATCH version when you make backward compatible bug fixes
> >
> >
> > So absolute literal "correctness" of what we're doing aside, our version
> numbers mean something to us as a dev community but also mean something to
> Cassandra users. I'm not confident they mean the same thing to each
> constituency. I'm also not comfortable with us prioritizing our own version
> number needs over that of our users, should they differ in meaning.
> >
> > Does anybody have insight into how other well known widely adopted
> projects do things we might be able to learn from? I generally only think
> about this topic when a discussion like this comes up on our dev list so
> don't have much insight to bring to the discussion.
> >
> > On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
> >
> > The question is if we are signaling compatibility or purely marketing
> with the release number.
> > We dropped compatibility with a few things in 5.0, which was the reason
> for the .0 rather than 4.2.  I don’t know if we are breaking any
> compatibility with current trunk?  Though maybe some of the TCM stuff could
> be considered that.
> > If we are purely going for marketing value, then yes, I agree TCM+Accord
> would be 6.0 worthy.
> >
> > -Jeremiah
> >
> > On Dec 10, 2024 at 10:48:21 AM, Jon Haddad 
> wrote:
> >
> > Keeping this short.  I'm not sure why we're calling the next release
> 5.1.  TCM and Accord are a massive thing.  Other .1 / .2 releases were the
> .0 with some smaller things added.  Imo this is a huge step forward, as big
> as 5.0 was, so we should call it 6.0.
> >
> >
>

Re: [DISCUSS] 5.1 should be 6.0

[Caleb Rackliffe]

I don't care what we call it as long as 4.1 -> 5.1/6.0 upgrades are
possible.

On Tue, Dec 10, 2024 at 1:28 PM David Capwell  wrote:

> Given our version support… if we do make this change does this imply users
> must do the following to get to 6.0?
>
> 4.x upgrade to 5.0
> 5.0 upgrade to 6.0
>
> So no 4.x to 6.0?  Given that this is 5.1 atm we are expected to support
> 4.x to 5.1 upgrades, but switching to 6.0 that isn’t true based off our
> documentation
>
> On Dec 10, 2024, at 11:00 AM, Josh McKenzie  wrote:
>
> This is another topic we basically revisit afresh every time :)
>
> I think it’s fine to bump for marketing or vibe reasons, I would support
> it. I don’t think we need to confect some weak semverish justification.
>
> Vibes ftw.
>
> Lets see if any strong contradicting opinions pop up on here in the next
> few days; if not I'll draft up a revision to the wiki. Taking it on a
> case-by-case release basis w/a respect for vibes sounds perfect to me.
>
> On Tue, Dec 10, 2024, at 1:37 PM, Patrick McFadin wrote:
>
> I was waiting for this discussion to happen again. :p
>
> What you call marketing, I call end-user communication. I'll leave
> this open question, but what do we want to communicate to the user
> base, and how should they approach this new feature set?
>
> Patrick
>
> On Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith
>  wrote:
> >
> > This is another topic we basically revisit afresh every time :)
> >
> > I think it’s fine to bump for marketing or vibe reasons, I would support
> it. I don’t think we need to confect some weak semverish justification.
> >
> > > On 10 Dec 2024, at 13:01, Brandon Williams  wrote:
> > >
> > > Even if TCM is api-compatible, it will change how operators run
> > > Cassandra in a significant way (like, different procedures from every
> > > previous version.)  I think that justifies a major.
> > >
> > > Kind Regards,
> > > Brandon
> > >
> > > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:
> > >>
> > >> You’ve added a ton of API surface to transaction behavior and cluster
> management. The TCM may or may not be strictly breaking, but they’re
> fundamentally very very different, so even with semver as the only
> standard, I think you can justify a major.
> > >>
> > >> But also, let’s just acknowledge that marketing is a thing and bump
> the major to acknowledge the huge, massive, database-changing features,
> even if they’re not meant to be disruptive.
> > >>
> > >>
> > >>
> > >> On Dec 10, 2024, at 9:46 AM, Josh McKenzie 
> wrote:
> > >>
> > >> Currently we reserve MAJOR in semver changes for API breaking only:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting
> :
> > >>
> > >> That's consistent w/semver itself: link:
> > >>
> > >> Given a version number MAJOR.MINOR.PATCH, increment the:
> > >>
> > >> MAJOR version when you make incompatible API changes
> > >> MINOR version when you add functionality in a backward compatible
> manner
> > >> PATCH version when you make backward compatible bug fixes
> > >>
> > >>
> > >> So absolute literal "correctness" of what we're doing aside, our
> version numbers mean something to us as a dev community but also mean
> something to Cassandra users. I'm not confident they mean the same thing to
> each constituency. I'm also not comfortable with us prioritizing our own
> version number needs over that of our users, should they differ in meaning.
> > >>
> > >> Does anybody have insight into how other well known widely adopted
> projects do things we might be able to learn from? I generally only think
> about this topic when a discussion like this comes up on our dev list so
> don't have much insight to bring to the discussion.
> > >>
> > >> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
> > >>
> > >> The question is if we are signaling compatibility or purely marketing
> with the release number.
> > >> We dropped compatibility with a few things in 5.0, which was the
> reason for the .0 rather than 4.2.  I don’t know if we are breaking any
> compatibility with current trunk?  Though maybe some of the TCM stuff could
> be considered that.
> > >> If we are purely going for marketing value, then yes, I agree
> TCM+Accord would be 6.0 worthy.
> > >>
> > >> -Jeremiah
> > >>
> > >> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad 
> wrote:
> > >>
> > >> Keeping this short.  I'm not sure why we're calling the next release
> 5.1.  TCM and Accord are a massive thing.  Other .1 / .2 releases were the
> .0 with some smaller things added.  Imo this is a huge step forward, as big
> as 5.0 was, so we should call it 6.0.
> > >>
> > >>
> >
>
>
>

Re: [DISCUSS] 5.1 should be 6.0

[David Capwell]

Given our version support… if we do make this change does this imply users must 
do the following to get to 6.0?

4.x upgrade to 5.0
5.0 upgrade to 6.0

So no 4.x to 6.0?  Given that this is 5.1 atm we are expected to support 4.x to 
5.1 upgrades, but switching to 6.0 that isn’t true based off our documentation

> On Dec 10, 2024, at 11:00 AM, Josh McKenzie  wrote:
> 
>> This is another topic we basically revisit afresh every time :) 
>> 
>> I think it’s fine to bump for marketing or vibe reasons, I would support it. 
>> I don’t think we need to confect some weak semverish justification.
> Vibes ftw.
> 
> Lets see if any strong contradicting opinions pop up on here in the next few 
> days; if not I'll draft up a revision to the wiki. Taking it on a 
> case-by-case release basis w/a respect for vibes sounds perfect to me.
> 
> On Tue, Dec 10, 2024, at 1:37 PM, Patrick McFadin wrote:
>> I was waiting for this discussion to happen again. :p
>> 
>> What you call marketing, I call end-user communication. I'll leave
>> this open question, but what do we want to communicate to the user
>> base, and how should they approach this new feature set?
>> 
>> Patrick
>> 
>> On Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith
>> mailto:bened...@apache.org>> wrote:
>> >
>> > This is another topic we basically revisit afresh every time :)
>> >
>> > I think it’s fine to bump for marketing or vibe reasons, I would support 
>> > it. I don’t think we need to confect some weak semverish justification.
>> >
>> > > On 10 Dec 2024, at 13:01, Brandon Williams > > > > wrote:
>> > >
>> > > Even if TCM is api-compatible, it will change how operators run
>> > > Cassandra in a significant way (like, different procedures from every
>> > > previous version.)  I think that justifies a major.
>> > >
>> > > Kind Regards,
>> > > Brandon
>> > >
>> > > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa > > > > wrote:
>> > >>
>> > >> You’ve added a ton of API surface to transaction behavior and cluster 
>> > >> management. The TCM may or may not be strictly breaking, but they’re 
>> > >> fundamentally very very different, so even with semver as the only 
>> > >> standard, I think you can justify a major.
>> > >>
>> > >> But also, let’s just acknowledge that marketing is a thing and bump the 
>> > >> major to acknowledge the huge, massive, database-changing features, 
>> > >> even if they’re not meant to be disruptive.
>> > >>
>> > >>
>> > >>
>> > >> On Dec 10, 2024, at 9:46 AM, Josh McKenzie > > >> > wrote:
>> > >>
>> > >> Currently we reserve MAJOR in semver changes for API breaking only: 
>> > >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting:
>> > >>
>> > >> That's consistent w/semver itself: link:
>> > >>
>> > >> Given a version number MAJOR.MINOR.PATCH, increment the:
>> > >>
>> > >> MAJOR version when you make incompatible API changes
>> > >> MINOR version when you add functionality in a backward compatible manner
>> > >> PATCH version when you make backward compatible bug fixes
>> > >>
>> > >>
>> > >> So absolute literal "correctness" of what we're doing aside, our 
>> > >> version numbers mean something to us as a dev community but also mean 
>> > >> something to Cassandra users. I'm not confident they mean the same 
>> > >> thing to each constituency. I'm also not comfortable with us 
>> > >> prioritizing our own version number needs over that of our users, 
>> > >> should they differ in meaning.
>> > >>
>> > >> Does anybody have insight into how other well known widely adopted 
>> > >> projects do things we might be able to learn from? I generally only 
>> > >> think about this topic when a discussion like this comes up on our dev 
>> > >> list so don't have much insight to bring to the discussion.
>> > >>
>> > >> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
>> > >>
>> > >> The question is if we are signaling compatibility or purely marketing 
>> > >> with the release number.
>> > >> We dropped compatibility with a few things in 5.0, which was the reason 
>> > >> for the .0 rather than 4.2.  I don’t know if we are breaking any 
>> > >> compatibility with current trunk?  Though maybe some of the TCM stuff 
>> > >> could be considered that.
>> > >> If we are purely going for marketing value, then yes, I agree 
>> > >> TCM+Accord would be 6.0 worthy.
>> > >>
>> > >> -Jeremiah
>> > >>
>> > >> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad > > >> > wrote:
>> > >>
>> > >> Keeping this short.  I'm not sure why we're calling the next release 
>> > >> 5.1.  TCM and Accord are a massive thing.  Other .1 / .2 releases were 
>> > >> the .0 with some smaller things added.  Imo this is a huge step 
>> > >> forward, as big as 5.0 was, so we should call it 6.0.
>> > >>
>> > >>
>> >

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

> This is another topic we basically revisit afresh every time :) 
> 
> I think it’s fine to bump for marketing or vibe reasons, I would support it. 
> I don’t think we need to confect some weak semverish justification.
Vibes ftw.

Lets see if any strong contradicting opinions pop up on here in the next few 
days; if not I'll draft up a revision to the wiki. Taking it on a case-by-case 
release basis w/a respect for vibes sounds perfect to me.

On Tue, Dec 10, 2024, at 1:37 PM, Patrick McFadin wrote:
> I was waiting for this discussion to happen again. :p
> 
> What you call marketing, I call end-user communication. I'll leave
> this open question, but what do we want to communicate to the user
> base, and how should they approach this new feature set?
> 
> Patrick
> 
> On Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith
>  wrote:
> >
> > This is another topic we basically revisit afresh every time :)
> >
> > I think it’s fine to bump for marketing or vibe reasons, I would support 
> > it. I don’t think we need to confect some weak semverish justification.
> >
> > > On 10 Dec 2024, at 13:01, Brandon Williams  wrote:
> > >
> > > Even if TCM is api-compatible, it will change how operators run
> > > Cassandra in a significant way (like, different procedures from every
> > > previous version.)  I think that justifies a major.
> > >
> > > Kind Regards,
> > > Brandon
> > >
> > > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:
> > >>
> > >> You’ve added a ton of API surface to transaction behavior and cluster 
> > >> management. The TCM may or may not be strictly breaking, but they’re 
> > >> fundamentally very very different, so even with semver as the only 
> > >> standard, I think you can justify a major.
> > >>
> > >> But also, let’s just acknowledge that marketing is a thing and bump the 
> > >> major to acknowledge the huge, massive, database-changing features, even 
> > >> if they’re not meant to be disruptive.
> > >>
> > >>
> > >>
> > >> On Dec 10, 2024, at 9:46 AM, Josh McKenzie  wrote:
> > >>
> > >> Currently we reserve MAJOR in semver changes for API breaking only: 
> > >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting:
> > >>
> > >> That's consistent w/semver itself: link:
> > >>
> > >> Given a version number MAJOR.MINOR.PATCH, increment the:
> > >>
> > >> MAJOR version when you make incompatible API changes
> > >> MINOR version when you add functionality in a backward compatible manner
> > >> PATCH version when you make backward compatible bug fixes
> > >>
> > >>
> > >> So absolute literal "correctness" of what we're doing aside, our version 
> > >> numbers mean something to us as a dev community but also mean something 
> > >> to Cassandra users. I'm not confident they mean the same thing to each 
> > >> constituency. I'm also not comfortable with us prioritizing our own 
> > >> version number needs over that of our users, should they differ in 
> > >> meaning.
> > >>
> > >> Does anybody have insight into how other well known widely adopted 
> > >> projects do things we might be able to learn from? I generally only 
> > >> think about this topic when a discussion like this comes up on our dev 
> > >> list so don't have much insight to bring to the discussion.
> > >>
> > >> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
> > >>
> > >> The question is if we are signaling compatibility or purely marketing 
> > >> with the release number.
> > >> We dropped compatibility with a few things in 5.0, which was the reason 
> > >> for the .0 rather than 4.2.  I don’t know if we are breaking any 
> > >> compatibility with current trunk?  Though maybe some of the TCM stuff 
> > >> could be considered that.
> > >> If we are purely going for marketing value, then yes, I agree TCM+Accord 
> > >> would be 6.0 worthy.
> > >>
> > >> -Jeremiah
> > >>
> > >> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad  
> > >> wrote:
> > >>
> > >> Keeping this short.  I'm not sure why we're calling the next release 
> > >> 5.1.  TCM and Accord are a massive thing.  Other .1 / .2 releases were 
> > >> the .0 with some smaller things added.  Imo this is a huge step forward, 
> > >> as big as 5.0 was, so we should call it 6.0.
> > >>
> > >>
> >
> 

Re: [DISCUSS] 5.1 should be 6.0

[Patrick McFadin]

I was waiting for this discussion to happen again. :p

What you call marketing, I call end-user communication. I'll leave
this open question, but what do we want to communicate to the user
base, and how should they approach this new feature set?

Patrick

On Tue, Dec 10, 2024 at 10:10 AM Benedict Elliott Smith
 wrote:
>
> This is another topic we basically revisit afresh every time :)
>
> I think it’s fine to bump for marketing or vibe reasons, I would support it. 
> I don’t think we need to confect some weak semverish justification.
>
> > On 10 Dec 2024, at 13:01, Brandon Williams  wrote:
> >
> > Even if TCM is api-compatible, it will change how operators run
> > Cassandra in a significant way (like, different procedures from every
> > previous version.)  I think that justifies a major.
> >
> > Kind Regards,
> > Brandon
> >
> > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:
> >>
> >> You’ve added a ton of API surface to transaction behavior and cluster 
> >> management. The TCM may or may not be strictly breaking, but they’re 
> >> fundamentally very very different, so even with semver as the only 
> >> standard, I think you can justify a major.
> >>
> >> But also, let’s just acknowledge that marketing is a thing and bump the 
> >> major to acknowledge the huge, massive, database-changing features, even 
> >> if they’re not meant to be disruptive.
> >>
> >>
> >>
> >> On Dec 10, 2024, at 9:46 AM, Josh McKenzie  wrote:
> >>
> >> Currently we reserve MAJOR in semver changes for API breaking only: 
> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting:
> >>
> >> That's consistent w/semver itself: link:
> >>
> >> Given a version number MAJOR.MINOR.PATCH, increment the:
> >>
> >> MAJOR version when you make incompatible API changes
> >> MINOR version when you add functionality in a backward compatible manner
> >> PATCH version when you make backward compatible bug fixes
> >>
> >>
> >> So absolute literal "correctness" of what we're doing aside, our version 
> >> numbers mean something to us as a dev community but also mean something to 
> >> Cassandra users. I'm not confident they mean the same thing to each 
> >> constituency. I'm also not comfortable with us prioritizing our own 
> >> version number needs over that of our users, should they differ in meaning.
> >>
> >> Does anybody have insight into how other well known widely adopted 
> >> projects do things we might be able to learn from? I generally only think 
> >> about this topic when a discussion like this comes up on our dev list so 
> >> don't have much insight to bring to the discussion.
> >>
> >> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
> >>
> >> The question is if we are signaling compatibility or purely marketing with 
> >> the release number.
> >> We dropped compatibility with a few things in 5.0, which was the reason 
> >> for the .0 rather than 4.2.  I don’t know if we are breaking any 
> >> compatibility with current trunk?  Though maybe some of the TCM stuff 
> >> could be considered that.
> >> If we are purely going for marketing value, then yes, I agree TCM+Accord 
> >> would be 6.0 worthy.
> >>
> >> -Jeremiah
> >>
> >> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad  
> >> wrote:
> >>
> >> Keeping this short.  I'm not sure why we're calling the next release 5.1.  
> >> TCM and Accord are a massive thing.  Other .1 / .2 releases were the .0 
> >> with some smaller things added.  Imo this is a huge step forward, as big 
> >> as 5.0 was, so we should call it 6.0.
> >>
> >>
>

Re: [DISCUSS] 5.1 should be 6.0

[Ekaterina Dimitrova]

6.0 even just for the reasons Brandon mentioned sounds reasonable to me.
And I acknowledge there are more

On Tue, 10 Dec 2024 at 13:10, Benedict Elliott Smith 
wrote:

> This is another topic we basically revisit afresh every time :)
>
> I think it’s fine to bump for marketing or vibe reasons, I would support
> it. I don’t think we need to confect some weak semverish justification.
>
> > On 10 Dec 2024, at 13:01, Brandon Williams  wrote:
> >
> > Even if TCM is api-compatible, it will change how operators run
> > Cassandra in a significant way (like, different procedures from every
> > previous version.)  I think that justifies a major.
> >
> > Kind Regards,
> > Brandon
> >
> > On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:
> >>
> >> You’ve added a ton of API surface to transaction behavior and cluster
> management. The TCM may or may not be strictly breaking, but they’re
> fundamentally very very different, so even with semver as the only
> standard, I think you can justify a major.
> >>
> >> But also, let’s just acknowledge that marketing is a thing and bump the
> major to acknowledge the huge, massive, database-changing features, even if
> they’re not meant to be disruptive.
> >>
> >>
> >>
> >> On Dec 10, 2024, at 9:46 AM, Josh McKenzie 
> wrote:
> >>
> >> Currently we reserve MAJOR in semver changes for API breaking only:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting
> :
> >>
> >> That's consistent w/semver itself: link:
> >>
> >> Given a version number MAJOR.MINOR.PATCH, increment the:
> >>
> >> MAJOR version when you make incompatible API changes
> >> MINOR version when you add functionality in a backward compatible manner
> >> PATCH version when you make backward compatible bug fixes
> >>
> >>
> >> So absolute literal "correctness" of what we're doing aside, our
> version numbers mean something to us as a dev community but also mean
> something to Cassandra users. I'm not confident they mean the same thing to
> each constituency. I'm also not comfortable with us prioritizing our own
> version number needs over that of our users, should they differ in meaning.
> >>
> >> Does anybody have insight into how other well known widely adopted
> projects do things we might be able to learn from? I generally only think
> about this topic when a discussion like this comes up on our dev list so
> don't have much insight to bring to the discussion.
> >>
> >> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
> >>
> >> The question is if we are signaling compatibility or purely marketing
> with the release number.
> >> We dropped compatibility with a few things in 5.0, which was the reason
> for the .0 rather than 4.2.  I don’t know if we are breaking any
> compatibility with current trunk?  Though maybe some of the TCM stuff could
> be considered that.
> >> If we are purely going for marketing value, then yes, I agree
> TCM+Accord would be 6.0 worthy.
> >>
> >> -Jeremiah
> >>
> >> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad 
> wrote:
> >>
> >> Keeping this short.  I'm not sure why we're calling the next release
> 5.1.  TCM and Accord are a massive thing.  Other .1 / .2 releases were the
> .0 with some smaller things added.  Imo this is a huge step forward, as big
> as 5.0 was, so we should call it 6.0.
> >>
> >>
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Benedict Elliott Smith]

This is another topic we basically revisit afresh every time :) 

I think it’s fine to bump for marketing or vibe reasons, I would support it. I 
don’t think we need to confect some weak semverish justification.

> On 10 Dec 2024, at 13:01, Brandon Williams  wrote:
> 
> Even if TCM is api-compatible, it will change how operators run
> Cassandra in a significant way (like, different procedures from every
> previous version.)  I think that justifies a major.
> 
> Kind Regards,
> Brandon
> 
> On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:
>> 
>> You’ve added a ton of API surface to transaction behavior and cluster 
>> management. The TCM may or may not be strictly breaking, but they’re 
>> fundamentally very very different, so even with semver as the only standard, 
>> I think you can justify a major.
>> 
>> But also, let’s just acknowledge that marketing is a thing and bump the 
>> major to acknowledge the huge, massive, database-changing features, even if 
>> they’re not meant to be disruptive.
>> 
>> 
>> 
>> On Dec 10, 2024, at 9:46 AM, Josh McKenzie  wrote:
>> 
>> Currently we reserve MAJOR in semver changes for API breaking only: 
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting:
>> 
>> That's consistent w/semver itself: link:
>> 
>> Given a version number MAJOR.MINOR.PATCH, increment the:
>> 
>> MAJOR version when you make incompatible API changes
>> MINOR version when you add functionality in a backward compatible manner
>> PATCH version when you make backward compatible bug fixes
>> 
>> 
>> So absolute literal "correctness" of what we're doing aside, our version 
>> numbers mean something to us as a dev community but also mean something to 
>> Cassandra users. I'm not confident they mean the same thing to each 
>> constituency. I'm also not comfortable with us prioritizing our own version 
>> number needs over that of our users, should they differ in meaning.
>> 
>> Does anybody have insight into how other well known widely adopted projects 
>> do things we might be able to learn from? I generally only think about this 
>> topic when a discussion like this comes up on our dev list so don't have 
>> much insight to bring to the discussion.
>> 
>> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
>> 
>> The question is if we are signaling compatibility or purely marketing with 
>> the release number.
>> We dropped compatibility with a few things in 5.0, which was the reason for 
>> the .0 rather than 4.2.  I don’t know if we are breaking any compatibility 
>> with current trunk?  Though maybe some of the TCM stuff could be considered 
>> that.
>> If we are purely going for marketing value, then yes, I agree TCM+Accord 
>> would be 6.0 worthy.
>> 
>> -Jeremiah
>> 
>> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad  wrote:
>> 
>> Keeping this short.  I'm not sure why we're calling the next release 5.1.  
>> TCM and Accord are a massive thing.  Other .1 / .2 releases were the .0 with 
>> some smaller things added.  Imo this is a huge step forward, as big as 5.0 
>> was, so we should call it 6.0.
>> 
>> 

Re: [DISCUSS] 5.1 should be 6.0

[Brandon Williams]

Even if TCM is api-compatible, it will change how operators run
Cassandra in a significant way (like, different procedures from every
previous version.)  I think that justifies a major.

Kind Regards,
Brandon

On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa  wrote:
>
> You’ve added a ton of API surface to transaction behavior and cluster 
> management. The TCM may or may not be strictly breaking, but they’re 
> fundamentally very very different, so even with semver as the only standard, 
> I think you can justify a major.
>
> But also, let’s just acknowledge that marketing is a thing and bump the major 
> to acknowledge the huge, massive, database-changing features, even if they’re 
> not meant to be disruptive.
>
>
>
> On Dec 10, 2024, at 9:46 AM, Josh McKenzie  wrote:
>
> Currently we reserve MAJOR in semver changes for API breaking only: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting:
>
> That's consistent w/semver itself: link:
>
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> MAJOR version when you make incompatible API changes
> MINOR version when you add functionality in a backward compatible manner
> PATCH version when you make backward compatible bug fixes
>
>
> So absolute literal "correctness" of what we're doing aside, our version 
> numbers mean something to us as a dev community but also mean something to 
> Cassandra users. I'm not confident they mean the same thing to each 
> constituency. I'm also not comfortable with us prioritizing our own version 
> number needs over that of our users, should they differ in meaning.
>
> Does anybody have insight into how other well known widely adopted projects 
> do things we might be able to learn from? I generally only think about this 
> topic when a discussion like this comes up on our dev list so don't have much 
> insight to bring to the discussion.
>
> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
>
> The question is if we are signaling compatibility or purely marketing with 
> the release number.
> We dropped compatibility with a few things in 5.0, which was the reason for 
> the .0 rather than 4.2.  I don’t know if we are breaking any compatibility 
> with current trunk?  Though maybe some of the TCM stuff could be considered 
> that.
> If we are purely going for marketing value, then yes, I agree TCM+Accord 
> would be 6.0 worthy.
>
> -Jeremiah
>
> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad  wrote:
>
> Keeping this short.  I'm not sure why we're calling the next release 5.1.  
> TCM and Accord are a massive thing.  Other .1 / .2 releases were the .0 with 
> some smaller things added.  Imo this is a huge step forward, as big as 5.0 
> was, so we should call it 6.0.
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Jeff Jirsa]

You’ve added a ton of API surface to transaction behavior and cluster 
management. The TCM may or may not be strictly breaking, but they’re 
fundamentally very very different, so even with semver as the only standard, I 
think you can justify a major.

But also, let’s just acknowledge that marketing is a thing and bump the major 
to acknowledge the huge, massive, database-changing features, even if they’re 
not meant to be disruptive.



> On Dec 10, 2024, at 9:46 AM, Josh McKenzie  wrote:
> 
> Currently we reserve MAJOR in semver changes for API breaking only: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting:
> 
> That's consistent w/semver itself: link 
> :
>> Given a version number MAJOR.MINOR.PATCH, increment the:
>> MAJOR version when you make incompatible API changes
>> MINOR version when you add functionality in a backward compatible manner
>> PATCH version when you make backward compatible bug fixes
> 
> So absolute literal "correctness" of what we're doing aside, our version 
> numbers mean something to us as a dev community but also mean something to 
> Cassandra users. I'm not confident they mean the same thing to each 
> constituency. I'm also not comfortable with us prioritizing our own version 
> number needs over that of our users, should they differ in meaning.
> 
> Does anybody have insight into how other well known widely adopted projects 
> do things we might be able to learn from? I generally only think about this 
> topic when a discussion like this comes up on our dev list so don't have much 
> insight to bring to the discussion.
> 
> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
>> The question is if we are signaling compatibility or purely marketing with 
>> the release number.
>> We dropped compatibility with a few things in 5.0, which was the reason for 
>> the .0 rather than 4.2.  I don’t know if we are breaking any compatibility 
>> with current trunk?  Though maybe some of the TCM stuff could be considered 
>> that.
>> If we are purely going for marketing value, then yes, I agree TCM+Accord 
>> would be 6.0 worthy.
>> 
>> -Jeremiah
>> 
>> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad > > wrote:
>>> Keeping this short.  I'm not sure why we're calling the next release 5.1.  
>>> TCM and Accord are a massive thing.  Other .1 / .2 releases were the .0 
>>> with some smaller things added.  Imo this is a huge step forward, as big as 
>>> 5.0 was, so we should call it 6.0.

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

Currently we reserve MAJOR in semver changes for API breaking only: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting:

That's consistent w/semver itself: link 
:
> Given a version number MAJOR.MINOR.PATCH, increment the:
>  1. MAJOR version when you make incompatible API changes
>  2. MINOR version when you add functionality in a backward compatible manner
>  3. PATCH version when you make backward compatible bug fixes

So absolute literal "correctness" of what we're doing aside, our version 
numbers mean something to us as a dev community but also mean something to 
Cassandra users. I'm not confident they mean the same thing to each 
constituency. I'm also not comfortable with us prioritizing our own version 
number needs over that of our users, should they differ in meaning.

Does anybody have insight into how other well known widely adopted projects do 
things we might be able to learn from? I generally only think about this topic 
when a discussion like this comes up on our dev list so don't have much insight 
to bring to the discussion.

On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
> The question is if we are signaling compatibility or purely marketing with 
> the release number.
> We dropped compatibility with a few things in 5.0, which was the reason for 
> the .0 rather than 4.2.  I don’t know if we are breaking any compatibility 
> with current trunk?  Though maybe some of the TCM stuff could be considered 
> that.
> If we are purely going for marketing value, then yes, I agree TCM+Accord 
> would be 6.0 worthy.
> 
> -Jeremiah
> 
> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad  wrote:
>> Keeping this short.  I'm not sure why we're calling the next release 5.1.  
>> TCM and Accord are a massive thing.  Other .1 / .2 releases were the .0 with 
>> some smaller things added.  Imo this is a huge step forward, as big as 5.0 
>> was, so we should call it 6.0.
>> 
>> 

Re: [DISCUSS] 5.1 should be 6.0

[Jeremiah Jordan]

 The question is if we are signaling compatibility or purely marketing with
the release number.
We dropped compatibility with a few things in 5.0, which was the reason for
the .0 rather than 4.2.  I don’t know if we are breaking any compatibility
with current trunk?  Though maybe some of the TCM stuff could be considered
that.
If we are purely going for marketing value, then yes, I agree TCM+Accord
would be 6.0 worthy.

-Jeremiah

On Dec 10, 2024 at 10:48:21 AM, Jon Haddad  wrote:

> Keeping this short.  I'm not sure why we're calling the next release 5.1.
> TCM and Accord are a massive thing.  Other .1 / .2 releases were the .0
> with some smaller things added.  Imo this is a huge step forward, as big as
> 5.0 was, so we should call it 6.0.
>
>
>