Re: [DISCUSS] Next release date

[Mick Semb Wever]

Thanks Caleb and JD, I'm keen to see us move forward.

Josh,
 I (and others) have expressed concern about trying to use dates, and
stating periods of time to achieve X, to work backwards from a desired GA
date.  Dates always slip, and we don't have the evidence (beyond
the extreme of 6 months for 4.1).  I feel this approach and such a
discussion will be far more appropriate and productive next year.

But that said, your breakdown is awesome, and the use of dates to specify
the _latest_ branch date works for me.

I would like to add that branching earlier than August 1st isn't just
impacting cep-21+15 engineers, but also all other engineers that have freed
up and where they want to start validation testing (i.e. again their desire
too for a stable base).

To my understanding the jdk17 work is still taking time, so I really don't
think we'll be much earlier than the 1st August if at all. Let's discuss it
again when it looks like we are approaching being ready to branch.



On Wed, 19 Apr 2023 at 17:13, Josh McKenzie  wrote:

> Let me try to break this down another way:
>
> I see a few competing concerns, each with QA related time requirements
> (asserting 8 weeks minimum, 16 weeks maximum we should plan for to
> stabilize a GA):
>
>1. A freeze to a branch to stabilize for release (8-16 weeks of QA
>required after we branch)
>2. A freeze to a branch to make room for large complex work to have
>increased velocity on merge due to having a more stable destination (8-16
>weeks of QA required after they merge)
>3. A commitment to release once a year (for our purposes, we've
>defined this as calendar year) (8-16 weeks of QA required *before*).
>
> If we walk backwards from Dec 1, that means our latest date to freeze and
> validate a 5.0 branch would be Friday August 11; let's go with 1st Friday
> in August for simplicity, 2023-08-04. That would give us just over 16 weeks
> worst-case to stabilize.
>
> So we branch for 5.0 *at the latest* on 2023-08-04; I think we can all
> agree on this?
>
> So the next question: when do we branch for 5.0 *at the earliest*? Pros
> and cons of an earlier branch:
> Pros:
>
>- Earlier start of validation testing on a more stable base (no
>improvements or new features excepting CEP-15 and CEP-21)
>- Theoretically higher velocity of completion of CEP-15 and CEP-21
>(the team doing this can speak to the degree to which this is true)
>
> Cons:
>
>- Smaller amount of improvements and new features go into 5.0
>- The rest of the dev community has another branch they need to target
>with bugfixes (annoying but not _too_ costly since bugfixes are often a bit
>smaller in scope)
>
>
> Through this lens, we are weighing the belief that CEP-15 and CEP-21 will
> land by August 1st and be accelerated by branching early against the belief
> that other improvements and features will go in if we branch later; if we
> freeze today and neither CEP-15 nor CEP-21 land for unforeseen reasons, we
> will have a GA release that had a shortened amount of time for new features
> and improvements to be merged in.
>
> Lastly, as input data to the discussion, here's a list of all the new
> features and improvements in 5.0 as of today; hypothetically were we to
> freeze 5.0 today and worst-case unforeseen things lead to CEP-21 and CEP-15
> not landing by cutoff, this would be our feature-set for our next GA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20and%20fixversion%20%3D%205.0%20and%20fixversion%20not%20in%20(4.0.x%2C%204.1.x%2C%204.0%2C%204.1%2C%204.1.1%2C%204.1.2%2C%204.0.8%2C%204.1-alpha1%2C%204.1-alpha1%2C%204.1-beta2%2C%204.1-beta1%2C%204.1-rc1)%20and%20type%20in%20(%22New%20Feature%22%2C%20%22Improvement%22)%20and%20component%20!%3D%20Accord%20order%20by%20type%20desc%2C%20resolved%20desc
>
> Phew. Ok, so using the above framework, I'm personally ok with us freezing
> 5.0 earlier than August 1st if the engineers actively on CEP-15 and CEP-21
> indicate that it will appreciably increase their velocity. The list of
> improvements and features is substantial enough that an earlier freeze
> would still have enough in it to be "meaty" in my opinion; especially given
> the likelihood of CEP-25 (Trie-indexed SSTable format) landing relatively
> soon.
>
> So the next question to me is: "when"? On that I defer to Sam, Alex,
> Benedict, Blake, David, et. al: how much would freezing 5.0 early help in
> terms of your development velocity on TrM and Accord?
>
>
> On Wed, Apr 19, 2023, at 6:22 AM, Henrik Ingo wrote:
>
> I'm going to repeat the point from my own thread: rather than thinking of
> this as some kind of concession to two exceptional CEPs, could we rather
> take the point of view that they get their own space and time precisely
> because they are large and invasive and both the merge and testing of them
> will benefit from everything else in the branch quieting down?
>
> I'm also not particularly interested in a long featu

Re: [DISCUSS] Next release date

[Josh McKenzie]

Let me try to break this down another way:

I see a few competing concerns, each with QA related time requirements 
(asserting 8 weeks minimum, 16 weeks maximum we should plan for to stabilize a 
GA):
 1. A freeze to a branch to stabilize for release (8-16 weeks of QA required 
after we branch)
 2. A freeze to a branch to make room for large complex work to have increased 
velocity on merge due to having a more stable destination (8-16 weeks of QA 
required after they merge)
 3. A commitment to release once a year (for our purposes, we've defined this 
as calendar year) (8-16 weeks of QA required *before*).
If we walk backwards from Dec 1, that means our latest date to freeze and 
validate a 5.0 branch would be Friday August 11; let's go with 1st Friday in 
August for simplicity, 2023-08-04. That would give us just over 16 weeks 
worst-case to stabilize.

So we branch for 5.0 *at the latest* on 2023-08-04; I think we can all agree on 
this?

So the next question: when do we branch for 5.0 *at the earliest*? Pros and 
cons of an earlier branch:
Pros:
 • Earlier start of validation testing on a more stable base (no improvements 
or new features excepting CEP-15 and CEP-21)
 • Theoretically higher velocity of completion of CEP-15 and CEP-21 (the team 
doing this can speak to the degree to which this is true)
Cons:
 • Smaller amount of improvements and new features go into 5.0
 • The rest of the dev community has another branch they need to target with 
bugfixes (annoying but not _too_ costly since bugfixes are often a bit smaller 
in scope)

Through this lens, we are weighing the belief that CEP-15 and CEP-21 will land 
by August 1st and be accelerated by branching early against the belief that 
other improvements and features will go in if we branch later; if we freeze 
today and neither CEP-15 nor CEP-21 land for unforeseen reasons, we will have a 
GA release that had a shortened amount of time for new features and 
improvements to be merged in.

Lastly, as input data to the discussion, here's a list of all the new features 
and improvements in 5.0 as of today; hypothetically were we to freeze 5.0 today 
and worst-case unforeseen things lead to CEP-21 and CEP-15 not landing by 
cutoff, this would be our feature-set for our next GA: 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20and%20fixversion%20%3D%205.0%20and%20fixversion%20not%20in%20(4.0.x%2C%204.1.x%2C%204.0%2C%204.1%2C%204.1.1%2C%204.1.2%2C%204.0.8%2C%204.1-alpha1%2C%204.1-alpha1%2C%204.1-beta2%2C%204.1-beta1%2C%204.1-rc1)%20and%20type%20in%20(%22New%20Feature%22%2C%20%22Improvement%22)%20and%20component%20!%3D%20Accord%20order%20by%20type%20desc%2C%20resolved%20desc

Phew. Ok, so using the above framework, I'm personally ok with us freezing 5.0 
earlier than August 1st if the engineers actively on CEP-15 and CEP-21 indicate 
that it will appreciably increase their velocity. The list of improvements and 
features is substantial enough that an earlier freeze would still have enough 
in it to be "meaty" in my opinion; especially given the likelihood of CEP-25 
(Trie-indexed SSTable format) landing relatively soon.

So the next question to me is: "when"? On that I defer to Sam, Alex, Benedict, 
Blake, David, et. al: how much would freezing 5.0 early help in terms of your 
development velocity on TrM and Accord?


On Wed, Apr 19, 2023, at 6:22 AM, Henrik Ingo wrote:
> I'm going to repeat the point from my own thread: rather than thinking of 
> this as some kind of concession to two exceptional CEPs, could we rather take 
> the point of view that they get their own space and time precisely because 
> they are large and invasive and both the merge and testing of them will 
> benefit from everything else in the branch quieting down?
> 
> I'm also not particularly interested in a long feature freeze beyond 1-3 
> months that would serve the above purpose well.
> 
> In short: the proposal should not be that everyone else just have to sit 
> still and wait for two late stragglers. The proposal is merely to organise 
> work such that we maximise velocity and quality for merging cep-15&21. 
> Anything beyond that should be judged differently.
> 
> On Tue, 18 Apr 2023, 23:48 J. D. Jordan,  wrote:
>> 
>> I also don’t really see the value in “freezing with exceptions for two giant 
>> changes to come after the freeze”.
>> 
>> -Jeremiah
>> 
>>> On Apr 18, 2023, at 1:08 PM, Caleb Rackliffe  
>>> wrote:
>>> 
>>> > Caleb, you appear to be the only one objecting, and it does not appear 
>>> > that you have made any compromises in this thread.
>>> 
>>> All I'm really objecting to is making special exceptions for particular 
>>> CEPs in relation to our freeze date. In other words, let's not have a 
>>> pseudo-freeze date and a "real" freeze date, when the thing that makes the 
>>> latter supposedly necessary is a very invasive change to the database that 
>>> risks our desired GA date. Also, again, I don't understand how cutting a 
>>> 5.0 branch

Re: [DISCUSS] Next release date

[Henrik Ingo]

I'm going to repeat the point from my own thread: rather than thinking of
this as some kind of concession to two exceptional CEPs, could we rather
take the point of view that they get their own space and time precisely
because they are large and invasive and both the merge and testing of them
will benefit from everything else in the branch quieting down?

I'm also not particularly interested in a long feature freeze beyond 1-3
months that would serve the above purpose well.

In short: the proposal should not be that everyone else just have to sit
still and wait for two late stragglers. The proposal is merely to organise
work such that we maximise velocity and quality for merging cep-15&21.
Anything beyond that should be judged differently.

On Tue, 18 Apr 2023, 23:48 J. D. Jordan,  wrote:

> I also don’t really see the value in “freezing with exceptions for two
> giant changes to come after the freeze”.
>
> -Jeremiah
>
> On Apr 18, 2023, at 1:08 PM, Caleb Rackliffe 
> wrote:
>
> 
> > Caleb, you appear to be the only one objecting, and it does not appear
> that you have made any compromises in this thread.
>
> All I'm really objecting to is making special exceptions for particular
> CEPs in relation to our freeze date. In other words, let's not have a
> pseudo-freeze date and a "real" freeze date, when the thing that makes the
> latter supposedly necessary is a very invasive change to the database that
> risks our desired GA date. Also, again, I don't understand how cutting a
> 5.0 branch makes anything substantially easier to start testing. Perhaps
> I'm the only one who thinks this. If so, I'm not going to make further
> noise about it.
>
> On Tue, Apr 18, 2023 at 7:26 AM Henrik Ingo 
> wrote:
>
>> I forgot one last night:
>>
>> From Benjamin we have a question that I think went unanswered?
>>
>> *> Should it not facilitate the work if the branch stops changing
>> heavily?*
>>
>> This is IMO a good perspective. To me it seems weird to be too hung up on
>> a "hard limit" on a specific day, when we are talking about merges where a
>> single merge / rebase takes more than one day. We will have to stop merging
>> smaller work to trunk anyway, when CEP-21 is being merged. No?
>>
>> henrik
>>
>> On Tue, Apr 18, 2023 at 3:24 AM Henrik Ingo 
>> wrote:
>>
>>> Trying to collect a few loose ends from across this thread
>>>
>>> *> I'm receptive to another definition of "stabilize", *
>>>
>>> I think the stabilization period implies more than just CI, which is
>>> mostly a function of unit tests working correctly. For example, at Datastax
>>> we have run a "large scale" test with >100 nodes, over several weeks, both
>>> for 4.0 and 4.1. For obvious reasons such tests can't run in nightly CI
>>> builds.
>>>
>>> Also it is not unusual that during the testing phase developers or
>>> specialized QA engineers can develop new tests (which are possibly added to
>>> CI) to improve coverage for and especially targeting new features in the
>>> release. For example the fixes to Paxos v2 were found by such work before
>>> 4.1.
>>>
>>> Finally, maybe it's a special case relevant only for  this release, but
>>> as a significant part of the Datastax team has been focused on porting
>>> these large existing features from DSE, and to get them merged before the
>>> original May date, we also have tens of bug fixes waiting to be upstreamed
>>> too. (It used to be an even 100, but I'm unsure what the count is today.)
>>>
>>> In fact! If you are worried about how to occupy yourself between a May
>>> "soft freeze" and September'ish hard freeze, you are welcome to chug on
>>> that backlog. The bug fixes are already public and ASL licensed, in the 4.0
>>> based branch here
>>> .
>>> Failed with an unknown error.
>>>
>>> *> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk
>>> invalidating stabilization and risk our 2023 GA date*
>>>
>>> I think this is the assumption that I personally disagree with. If this
>>> is true, why do we even bother running any CI before the CEP-21 merge? It
>>> will all be invalidated anyway, right?
>>>
>>> In my experience, it is beneficial to test as early as possible, and at
>>> different checkpoints during development. If we wouldn't  do it, and we
>>> find some issue in late November, then the window to search for the commit
>>> that introduced the regression is all the way back to the 4.1 GA. If on the
>>> other hand the same test was already rune during the soft freeze, then we
>>> can know that we may focus our search onto CEP-15 and CEP-21.
>>>
>>>
>>> *> get comfortable with cutting feature previews or snapshot alphas like
>>> we agreed to for earlier access to new stuff*
>>>
>>> Snapshots are in fact a valid compromise proposal: A snapshot would
>>> provide a constant version / point in time to focus testing on, but on the
>>> other hand would allow trunk (or the 5.0 branch, in other proposals) to
>>> remain open to new commits. Somewh

Re: [DISCUSS] Next release date

[J. D. Jordan]

That said I’m not opposed to Mick’s proposal. In Apache terms I am -0 on the proposal. So no need to try and convince me.  If others think it is the way forward let’s go with it.On Apr 18, 2023, at 1:48 PM, J. D. Jordan  wrote:I also don’t really see the value in “freezing with exceptions for two giant changes to come after the freeze”.-JeremiahOn Apr 18, 2023, at 1:08 PM, Caleb Rackliffe  wrote:> Caleb, you appear to be the only one objecting, and it does not appear that you have made any compromises in this thread.All I'm really objecting to is making special exceptions for particular CEPs in relation to our freeze date. In other words, let's not have a pseudo-freeze date and a "real" freeze date, when the thing that makes the latter supposedly necessary is a very invasive change to the database that risks our desired GA date. Also, again, I don't understand how cutting a 5.0 branch makes anything substantially easier to start testing. Perhaps I'm the only one who thinks this. If so, I'm not going to make further noise about it.On Tue, Apr 18, 2023 at 7:26 AM Henrik Ingo  wrote:I forgot one last night:From Benjamin we have a question that I think went unanswered?> Should it not facilitate the work if the branch stops changing heavily?This is IMO a good perspective. To me it seems weird to be too hung up on a "hard limit" on a specific day, when we are talking about merges where a single merge / rebase takes more than one day. We will have to stop merging smaller work to trunk anyway, when CEP-21 is being merged. No?henrikOn Tue, Apr 18, 2023 at 3:24 AM Henrik Ingo  wrote:Trying to collect a few loose ends from across this thread> I'm receptive to another definition of "stabilize", I think the stabilization period implies more than just CI, which is mostly a function of unit tests working correctly. For example, at Datastax we have run a "large scale" test with >100 nodes, over several weeks, both for 4.0 and 4.1. For obvious reasons such tests can't run in nightly CI builds.Also it is not unusual that during the testing phase developers or specialized QA engineers can develop new tests (which are possibly added to CI) to improve coverage for and especially targeting new features in the release. For example the fixes to Paxos v2 were found by such work before 4.1.Finally, maybe it's a special case relevant only for  this release, but as a significant part of the Datastax team has been focused on porting these large existing features from DSE, and to get them merged before the original May date, we also have tens of bug fixes waiting to be upstreamed too. (It used to be an even 100, but I'm unsure what the count is today.)In fact! If you are worried about how to occupy yourself between a May "soft freeze" and September'ish hard freeze, you are welcome to chug on that backlog. The bug fixes are already public and ASL licensed, in the 4.0 based branch here.Failed with an unknown error.> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk invalidating stabilization and risk our 2023 GA dateI think this is the assumption that I personally disagree with. If this is true, why do we even bother running any CI before the CEP-21 merge? It will all be invalidated anyway, right?In my experience, it is beneficial to test as early as possible, and at different checkpoints during development. If we wouldn't  do it, and we find some issue in late November, then the window to search for the commit that introduced the regression is all the way back to the 4.1 GA. If on the other hand the same test was already rune during the soft freeze, then we can know that we may focus our search onto CEP-15 and CEP-21.> get comfortable with cutting feature previews or snapshot alphas like we agreed to for earlier access to new stuffSnapshots are in fact a valid compromise proposal: A snapshot would provide a constant version / point in time to focus testing on, but on the other hand would allow trunk (or the 5.0 branch, in other proposals) to remain open to new commits. Somewhat "invalidating" the testing work, but presumably the branch will be relatively calm anyway. Which leads me to 2 important questions:WHO would be actively merging things into 5.0 during June-August? By my count at that point I expect most contributors to either furiously work on Acccord and TCM, or work on stabilization (tests, fixes).Also, if someone did contribute new feature code during this time, they might find it hard to get priority for reviews, if others are focused on the above tasks.Finally, I expect most Europeans to be on vacation 33% of that time. Non-Europeans may want to try it too!WHAT do we expect to get merged during June-August?Compared to the tens of thousands of lines of code being merged by Accord, SAI, UCS and Tries... I imagine even the worst case during a non-freeze in June-August would be just a tiny percentage of the large CEPs.In this thread I only see Paulo announcing an

Re: [DISCUSS] Next release date

[J. D. Jordan]

I also don’t really see the value in “freezing with exceptions for two giant changes to come after the freeze”.-JeremiahOn Apr 18, 2023, at 1:08 PM, Caleb Rackliffe  wrote:> Caleb, you appear to be the only one objecting, and it does not appear that you have made any compromises in this thread.All I'm really objecting to is making special exceptions for particular CEPs in relation to our freeze date. In other words, let's not have a pseudo-freeze date and a "real" freeze date, when the thing that makes the latter supposedly necessary is a very invasive change to the database that risks our desired GA date. Also, again, I don't understand how cutting a 5.0 branch makes anything substantially easier to start testing. Perhaps I'm the only one who thinks this. If so, I'm not going to make further noise about it.On Tue, Apr 18, 2023 at 7:26 AM Henrik Ingo  wrote:I forgot one last night:From Benjamin we have a question that I think went unanswered?> Should it not facilitate the work if the branch stops changing heavily?This is IMO a good perspective. To me it seems weird to be too hung up on a "hard limit" on a specific day, when we are talking about merges where a single merge / rebase takes more than one day. We will have to stop merging smaller work to trunk anyway, when CEP-21 is being merged. No?henrikOn Tue, Apr 18, 2023 at 3:24 AM Henrik Ingo  wrote:Trying to collect a few loose ends from across this thread> I'm receptive to another definition of "stabilize", I think the stabilization period implies more than just CI, which is mostly a function of unit tests working correctly. For example, at Datastax we have run a "large scale" test with >100 nodes, over several weeks, both for 4.0 and 4.1. For obvious reasons such tests can't run in nightly CI builds.Also it is not unusual that during the testing phase developers or specialized QA engineers can develop new tests (which are possibly added to CI) to improve coverage for and especially targeting new features in the release. For example the fixes to Paxos v2 were found by such work before 4.1.Finally, maybe it's a special case relevant only for  this release, but as a significant part of the Datastax team has been focused on porting these large existing features from DSE, and to get them merged before the original May date, we also have tens of bug fixes waiting to be upstreamed too. (It used to be an even 100, but I'm unsure what the count is today.)In fact! If you are worried about how to occupy yourself between a May "soft freeze" and September'ish hard freeze, you are welcome to chug on that backlog. The bug fixes are already public and ASL licensed, in the 4.0 based branch here.Failed with an unknown error.> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk invalidating stabilization and risk our 2023 GA dateI think this is the assumption that I personally disagree with. If this is true, why do we even bother running any CI before the CEP-21 merge? It will all be invalidated anyway, right?In my experience, it is beneficial to test as early as possible, and at different checkpoints during development. If we wouldn't  do it, and we find some issue in late November, then the window to search for the commit that introduced the regression is all the way back to the 4.1 GA. If on the other hand the same test was already rune during the soft freeze, then we can know that we may focus our search onto CEP-15 and CEP-21.> get comfortable with cutting feature previews or snapshot alphas like we agreed to for earlier access to new stuffSnapshots are in fact a valid compromise proposal: A snapshot would provide a constant version / point in time to focus testing on, but on the other hand would allow trunk (or the 5.0 branch, in other proposals) to remain open to new commits. Somewhat "invalidating" the testing work, but presumably the branch will be relatively calm anyway. Which leads me to 2 important questions:WHO would be actively merging things into 5.0 during June-August? By my count at that point I expect most contributors to either furiously work on Acccord and TCM, or work on stabilization (tests, fixes).Also, if someone did contribute new feature code during this time, they might find it hard to get priority for reviews, if others are focused on the above tasks.Finally, I expect most Europeans to be on vacation 33% of that time. Non-Europeans may want to try it too!WHAT do we expect to get merged during June-August?Compared to the tens of thousands of lines of code being merged by Accord, SAI, UCS and Tries... I imagine even the worst case during a non-freeze in June-August would be just a tiny percentage of the large CEPs.In this thread I only see Paulo announcing an intent to commit against trunk during a soft freeze, and even he agrees with a 5.0 branch freeze.This last question is basically a form of saying I hope we aren't discussing a problem that doesn't even exist?henrik-- Henrik Ing

Re: [DISCUSS] Next release date

[Caleb Rackliffe]

> Caleb, you appear to be the only one objecting, and it does not appear
that you have made any compromises in this thread.

All I'm really objecting to is making special exceptions for particular
CEPs in relation to our freeze date. In other words, let's not have a
pseudo-freeze date and a "real" freeze date, when the thing that makes the
latter supposedly necessary is a very invasive change to the database that
risks our desired GA date. Also, again, I don't understand how cutting a
5.0 branch makes anything substantially easier to start testing. Perhaps
I'm the only one who thinks this. If so, I'm not going to make further
noise about it.

On Tue, Apr 18, 2023 at 7:26 AM Henrik Ingo 
wrote:

> I forgot one last night:
>
> From Benjamin we have a question that I think went unanswered?
>
> *> Should it not facilitate the work if the branch stops changing heavily?*
>
> This is IMO a good perspective. To me it seems weird to be too hung up on
> a "hard limit" on a specific day, when we are talking about merges where a
> single merge / rebase takes more than one day. We will have to stop merging
> smaller work to trunk anyway, when CEP-21 is being merged. No?
>
> henrik
>
> On Tue, Apr 18, 2023 at 3:24 AM Henrik Ingo 
> wrote:
>
>> Trying to collect a few loose ends from across this thread
>>
>> *> I'm receptive to another definition of "stabilize", *
>>
>> I think the stabilization period implies more than just CI, which is
>> mostly a function of unit tests working correctly. For example, at Datastax
>> we have run a "large scale" test with >100 nodes, over several weeks, both
>> for 4.0 and 4.1. For obvious reasons such tests can't run in nightly CI
>> builds.
>>
>> Also it is not unusual that during the testing phase developers or
>> specialized QA engineers can develop new tests (which are possibly added to
>> CI) to improve coverage for and especially targeting new features in the
>> release. For example the fixes to Paxos v2 were found by such work before
>> 4.1.
>>
>> Finally, maybe it's a special case relevant only for  this release, but
>> as a significant part of the Datastax team has been focused on porting
>> these large existing features from DSE, and to get them merged before the
>> original May date, we also have tens of bug fixes waiting to be upstreamed
>> too. (It used to be an even 100, but I'm unsure what the count is today.)
>>
>> In fact! If you are worried about how to occupy yourself between a May
>> "soft freeze" and September'ish hard freeze, you are welcome to chug on
>> that backlog. The bug fixes are already public and ASL licensed, in the 4.0
>> based branch here
>> .
>> Failed with an unknown error.
>>
>> *> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk
>> invalidating stabilization and risk our 2023 GA date*
>>
>> I think this is the assumption that I personally disagree with. If this
>> is true, why do we even bother running any CI before the CEP-21 merge? It
>> will all be invalidated anyway, right?
>>
>> In my experience, it is beneficial to test as early as possible, and at
>> different checkpoints during development. If we wouldn't  do it, and we
>> find some issue in late November, then the window to search for the commit
>> that introduced the regression is all the way back to the 4.1 GA. If on the
>> other hand the same test was already rune during the soft freeze, then we
>> can know that we may focus our search onto CEP-15 and CEP-21.
>>
>>
>> *> get comfortable with cutting feature previews or snapshot alphas like
>> we agreed to for earlier access to new stuff*
>>
>> Snapshots are in fact a valid compromise proposal: A snapshot would
>> provide a constant version / point in time to focus testing on, but on the
>> other hand would allow trunk (or the 5.0 branch, in other proposals) to
>> remain open to new commits. Somewhat "invalidating" the testing work, but
>> presumably the branch will be relatively calm anyway. Which leads me to 2
>> important questions:
>>
>> *WHO would be actively merging things into 5.0 during June-August? *
>>
>> By my count at that point I expect most contributors to either furiously
>> work on Acccord and TCM, or work on stabilization (tests, fixes).
>>
>> Also, if someone did contribute new feature code during this time, they
>> might find it hard to get priority for reviews, if others are focused on
>> the above tasks.
>>
>> Finally, I expect most Europeans to be on vacation 33% of that time.
>> Non-Europeans may want to try it too!
>>
>>
>> *WHAT do we expect to get merged during June-August?*
>>
>> Compared to the tens of thousands of lines of code being merged by
>> Accord, SAI, UCS and Tries... I imagine even the worst case during a
>> non-freeze in June-August would be just a tiny percentage of the large CEPs.
>>
>> In this thread I only see Paulo announcing an intent to commit against
>> trunk during a soft freeze, and even he agrees with a 5.0 branch freeze

Re: [DISCUSS] Next release date

[Henrik Ingo]

I forgot one last night:

>From Benjamin we have a question that I think went unanswered?

*> Should it not facilitate the work if the branch stops changing heavily?*

This is IMO a good perspective. To me it seems weird to be too hung up on a
"hard limit" on a specific day, when we are talking about merges where a
single merge / rebase takes more than one day. We will have to stop merging
smaller work to trunk anyway, when CEP-21 is being merged. No?

henrik

On Tue, Apr 18, 2023 at 3:24 AM Henrik Ingo 
wrote:

> Trying to collect a few loose ends from across this thread
>
> *> I'm receptive to another definition of "stabilize", *
>
> I think the stabilization period implies more than just CI, which is
> mostly a function of unit tests working correctly. For example, at Datastax
> we have run a "large scale" test with >100 nodes, over several weeks, both
> for 4.0 and 4.1. For obvious reasons such tests can't run in nightly CI
> builds.
>
> Also it is not unusual that during the testing phase developers or
> specialized QA engineers can develop new tests (which are possibly added to
> CI) to improve coverage for and especially targeting new features in the
> release. For example the fixes to Paxos v2 were found by such work before
> 4.1.
>
> Finally, maybe it's a special case relevant only for  this release, but as
> a significant part of the Datastax team has been focused on porting these
> large existing features from DSE, and to get them merged before the
> original May date, we also have tens of bug fixes waiting to be upstreamed
> too. (It used to be an even 100, but I'm unsure what the count is today.)
>
> In fact! If you are worried about how to occupy yourself between a May
> "soft freeze" and September'ish hard freeze, you are welcome to chug on
> that backlog. The bug fixes are already public and ASL licensed, in the 4.0
> based branch here 
> .
> Failed with an unknown error.
>
> *> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk
> invalidating stabilization and risk our 2023 GA date*
>
> I think this is the assumption that I personally disagree with. If this is
> true, why do we even bother running any CI before the CEP-21 merge? It will
> all be invalidated anyway, right?
>
> In my experience, it is beneficial to test as early as possible, and at
> different checkpoints during development. If we wouldn't  do it, and we
> find some issue in late November, then the window to search for the commit
> that introduced the regression is all the way back to the 4.1 GA. If on the
> other hand the same test was already rune during the soft freeze, then we
> can know that we may focus our search onto CEP-15 and CEP-21.
>
>
> *> get comfortable with cutting feature previews or snapshot alphas like
> we agreed to for earlier access to new stuff*
>
> Snapshots are in fact a valid compromise proposal: A snapshot would
> provide a constant version / point in time to focus testing on, but on the
> other hand would allow trunk (or the 5.0 branch, in other proposals) to
> remain open to new commits. Somewhat "invalidating" the testing work, but
> presumably the branch will be relatively calm anyway. Which leads me to 2
> important questions:
>
> *WHO would be actively merging things into 5.0 during June-August? *
>
> By my count at that point I expect most contributors to either furiously
> work on Acccord and TCM, or work on stabilization (tests, fixes).
>
> Also, if someone did contribute new feature code during this time, they
> might find it hard to get priority for reviews, if others are focused on
> the above tasks.
>
> Finally, I expect most Europeans to be on vacation 33% of that time.
> Non-Europeans may want to try it too!
>
>
> *WHAT do we expect to get merged during June-August?*
>
> Compared to the tens of thousands of lines of code being merged by Accord,
> SAI, UCS and Tries... I imagine even the worst case during a non-freeze in
> June-August would be just a tiny percentage of the large CEPs.
>
> In this thread I only see Paulo announcing an intent to commit against
> trunk during a soft freeze, and even he agrees with a 5.0 branch freeze.
>
> This last question is basically a form of saying I hope we aren't
> discussing a problem that doesn't even exist?
>
> henrik
>
> --
>
> Henrik Ingo
>
> c. +358 40 569 7354
>
> w. www.datastax.com
>
>   
> 
> 
>
>

-- 

Henrik Ingo

c. +358 40 569 7354

w. www.datastax.com

  
  

Re: [DISCUSS] Next release date

[Benedict]

Finally, I expect most Europeans to be on vacation 33% of that time. Non-Europeans may want to try it too!The more northerly Europeans maybe :)On 18 Apr 2023, at 01:24, Henrik Ingo  wrote:Trying to collect a few loose ends from across this thread> I'm receptive to another definition of "stabilize", I think the stabilization period implies more than just CI, which is mostly a function of unit tests working correctly. For example, at Datastax we have run a "large scale" test with >100 nodes, over several weeks, both for 4.0 and 4.1. For obvious reasons such tests can't run in nightly CI builds.Also it is not unusual that during the testing phase developers or specialized QA engineers can develop new tests (which are possibly added to CI) to improve coverage for and especially targeting new features in the release. For example the fixes to Paxos v2 were found by such work before 4.1.Finally, maybe it's a special case relevant only for  this release, but as a significant part of the Datastax team has been focused on porting these large existing features from DSE, and to get them merged before the original May date, we also have tens of bug fixes waiting to be upstreamed too. (It used to be an even 100, but I'm unsure what the count is today.)In fact! If you are worried about how to occupy yourself between a May "soft freeze" and September'ish hard freeze, you are welcome to chug on that backlog. The bug fixes are already public and ASL licensed, in the 4.0 based branch here.Failed with an unknown error.> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk invalidating stabilization and risk our 2023 GA dateI think this is the assumption that I personally disagree with. If this is true, why do we even bother running any CI before the CEP-21 merge? It will all be invalidated anyway, right?In my experience, it is beneficial to test as early as possible, and at different checkpoints during development. If we wouldn't  do it, and we find some issue in late November, then the window to search for the commit that introduced the regression is all the way back to the 4.1 GA. If on the other hand the same test was already rune during the soft freeze, then we can know that we may focus our search onto CEP-15 and CEP-21.> get comfortable with cutting feature previews or snapshot alphas like we agreed to for earlier access to new stuffSnapshots are in fact a valid compromise proposal: A snapshot would provide a constant version / point in time to focus testing on, but on the other hand would allow trunk (or the 5.0 branch, in other proposals) to remain open to new commits. Somewhat "invalidating" the testing work, but presumably the branch will be relatively calm anyway. Which leads me to 2 important questions:WHO would be actively merging things into 5.0 during June-August? By my count at that point I expect most contributors to either furiously work on Acccord and TCM, or work on stabilization (tests, fixes).Also, if someone did contribute new feature code during this time, they might find it hard to get priority for reviews, if others are focused on the above tasks.Finally, I expect most Europeans to be on vacation 33% of that time. Non-Europeans may want to try it too!WHAT do we expect to get merged during June-August?Compared to the tens of thousands of lines of code being merged by Accord, SAI, UCS and Tries... I imagine even the worst case during a non-freeze in June-August would be just a tiny percentage of the large CEPs.In this thread I only see Paulo announcing an intent to commit against trunk during a soft freeze, and even he agrees with a 5.0 branch freeze.This last question is basically a form of saying I hope we aren't discussing a problem that doesn't even exist?henrik-- Henrik Ingoc. +358 40 569 7354 w. www.datastax.com      

Re: [DISCUSS] Next release date

[Josh McKenzie]

> If this is true, why do we even bother running any CI before the CEP-21 
> merge? It will all be invalidated anyway, right?
I'm referring to manual validation or soak testing in qa environments rather 
than automated. Just because a soft-frozen branch without those features works 
in QA doesn't mean a branch after those features merge will be equally 
qualified.

There's certainly value in rolling out a soft-frozen branch before those 
features merge, but we will also need to be very deliberate and clear about 
having a minimum bound of time for people to perform testing *after* these two 
features merge as well if we go the "freeze but let them merge after" route.

On Mon, Apr 17, 2023, at 5:12 PM, Mick Semb Wever wrote:
>> My personal .02: I think we should consider branching 5.0 September 1st. 
>> That gives us basically 12 weeks for folks to do their testing and for us to 
>> stabilize anything that's flaky in circle or regressed in ASF CI.
> 
> 
> I'm not for this, sorry. I see the real risk here of there being no GA 
> release this year.
> 
> My proposal was based on reading through the thread and gathering what I saw 
> to be the best middle ground for everyone. It's not my first choice, but as a 
> middle ground I can accept it.
> 
> Caleb, you appear to be the only one objecting, and it does not appear that 
> you have made any compromises in this thread. Can I ask that you do?  I (and 
> others) do see that letting testing start as soon as it can, where they can, 
> as an important tactic to de-risking an important 5.0 release.
> 
> 

Re: [DISCUSS] Next release date

[Henrik Ingo]

Trying to collect a few loose ends from across this thread

*> I'm receptive to another definition of "stabilize", *

I think the stabilization period implies more than just CI, which is mostly
a function of unit tests working correctly. For example, at Datastax we
have run a "large scale" test with >100 nodes, over several weeks, both for
4.0 and 4.1. For obvious reasons such tests can't run in nightly CI builds.

Also it is not unusual that during the testing phase developers or
specialized QA engineers can develop new tests (which are possibly added to
CI) to improve coverage for and especially targeting new features in the
release. For example the fixes to Paxos v2 were found by such work before
4.1.

Finally, maybe it's a special case relevant only for  this release, but as
a significant part of the Datastax team has been focused on porting these
large existing features from DSE, and to get them merged before the
original May date, we also have tens of bug fixes waiting to be upstreamed
too. (It used to be an even 100, but I'm unsure what the count is today.)

In fact! If you are worried about how to occupy yourself between a May
"soft freeze" and September'ish hard freeze, you are welcome to chug on
that backlog. The bug fixes are already public and ASL licensed, in the 4.0
based branch here .
Failed with an unknown error.

*> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk
invalidating stabilization and risk our 2023 GA date*

I think this is the assumption that I personally disagree with. If this is
true, why do we even bother running any CI before the CEP-21 merge? It will
all be invalidated anyway, right?

In my experience, it is beneficial to test as early as possible, and at
different checkpoints during development. If we wouldn't  do it, and we
find some issue in late November, then the window to search for the commit
that introduced the regression is all the way back to the 4.1 GA. If on the
other hand the same test was already rune during the soft freeze, then we
can know that we may focus our search onto CEP-15 and CEP-21.


*> get comfortable with cutting feature previews or snapshot alphas like we
agreed to for earlier access to new stuff*

Snapshots are in fact a valid compromise proposal: A snapshot would provide
a constant version / point in time to focus testing on, but on the other
hand would allow trunk (or the 5.0 branch, in other proposals) to remain
open to new commits. Somewhat "invalidating" the testing work, but
presumably the branch will be relatively calm anyway. Which leads me to 2
important questions:

*WHO would be actively merging things into 5.0 during June-August? *

By my count at that point I expect most contributors to either furiously
work on Acccord and TCM, or work on stabilization (tests, fixes).

Also, if someone did contribute new feature code during this time, they
might find it hard to get priority for reviews, if others are focused on
the above tasks.

Finally, I expect most Europeans to be on vacation 33% of that time.
Non-Europeans may want to try it too!


*WHAT do we expect to get merged during June-August?*

Compared to the tens of thousands of lines of code being merged by Accord,
SAI, UCS and Tries... I imagine even the worst case during a non-freeze in
June-August would be just a tiny percentage of the large CEPs.

In this thread I only see Paulo announcing an intent to commit against
trunk during a soft freeze, and even he agrees with a 5.0 branch freeze.

This last question is basically a form of saying I hope we aren't
discussing a problem that doesn't even exist?

henrik

-- 

Henrik Ingo

c. +358 40 569 7354

w. www.datastax.com

  
  

Re: [DISCUSS] Next release date

[Mick Semb Wever]

>
> My personal .02: I think we should consider branching 5.0 September 1st.
> That gives us basically 12 weeks for folks to do their testing and for us
> to stabilize anything that's flaky in circle or regressed in ASF CI.
>


I'm not for this, sorry. I see the real risk here of there being no GA
release this year.

My proposal was based on reading through the thread and gathering what I
saw to be the best middle ground for everyone. It's not my first choice,
but as a middle ground I can accept it.

Caleb, you appear to be the only one objecting, and it does not appear that
you have made any compromises in this thread. Can I ask that you do?  I
(and others) do see that letting testing start as soon as it can, where
they can, as an important tactic to de-risking an important 5.0 release.

Re: [DISCUSS] Next release date

[Josh McKenzie]

> WFM, if that means we branch there and anything not already merged has to wait
I think there might be value in us exploring the "how we cut snapshots" in 
terms of allowing us to fast-follow for big features folks may want to get 
their hands on. If we stick to the same "green circle no regression ASF", I 
suspect we'd be in a pretty good position overall to cut a snapshot from trunk 
quarterly as we discussed.

And to be clear, I am 100% uninterested in us re-opening the Pandora's Box Of 
Sadness that was the semver discussion on this thread :). If we all still agree 
that cutting snapshots is good, and that's a way for us to "have our cake and 
eat it too" when it comes to sticking with a train model, then I think the ends 
justify the means and we can zombie the other thread and power through it.

On Mon, Apr 17, 2023, at 4:39 PM, Caleb Rackliffe wrote:
> > My personal .02: I think we should consider branching 5.0 September 1st. 
> > That gives us basically 12 weeks for folks to do their testing and for us 
> > to stabilize anything that's flaky in circle or regressed in ASF CI.
> 
> WFM, if that means we branch there and anything not already merged has to wait
> 
> 
> On Mon, Apr 17, 2023 at 3:37 PM Josh McKenzie  wrote:
>> __
>>> it's (b) for me, and everything minus 21 and 15 is defining enough to 
>>> warrant the branching and a checkpoint where testing can start
>> Ok, I don't follow.
>> 
>> There's three different ways I can read what you're saying here:
>>  1. "Everything we have targeting 5.x is substantial and we can branch when 
>> it's done", that'd mean 600+ open tickets, so it can't be that: 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%205.x%20and%20resolution%20%3D%20unresolved
>>  2. "Everything we've *already merged today* targeting 5.x is substantial 
>> and we can branch now"... I don't think that's quite right? Since that'd put 
>> the release far too early after December '22.
>>  3. "Everything we expect to merge by August 1st, regardless of CEP-21 and 
>> CEP-15, is substantial enough for us to cut a release then" - that's arguing 
>> for a feature-driven release rather than a train right?
>> Sorry; I'm definitely not *trying* to be obtuse, I'm just having a hard time 
>> understanding how what the two of you are saying actually lines up.
>> 
>> My personal .02: I think we should consider branching 5.0 September 1st. 
>> That gives us basically 12 weeks for folks to do their testing and for us to 
>> stabilize anything that's flaky in circle or regressed in ASF CI.
>> 
>> If CEP-15 or CEP-21 land shortly after (early September), we can cross that 
>> bridge when the time comes.
>> 
>> That's my hot take. We move to a train model and stick with it, and we start 
>> to get comfortable with cutting feature previews or snapshot alphas like we 
>> agreed to for earlier access to new stuff.
>> 
>> On Mon, Apr 17, 2023, at 4:25 PM, Mick Semb Wever wrote:
>>> 
 b.) Cut a 5.0 branch when the major release-defining element (maybe 
 CEP-21?) merges to trunk, with the shared understanding (possibly what 
 we're disagreeing about) that very little of what we need to test/de-risk 
 is going to be inhibited by not cutting that branch earlier (and that 
 certain testing efforts would be almost wholesale wasted if done 
 beforehand).
>>> 
>>> 
>>> Yup, it's (b) for me, and everything minus 21 and 15 is defining enough to 
>>> warrant the branching and a checkpoint where testing can start and not be 
>>> wasted.  I understand that cep-21 changes a lot and that impacts testing, 
>>> but I wholeheartedly trust testers to be taking this into consideration. 
>>> 
>> 

Re: [DISCUSS] Next release date

[Caleb Rackliffe]

> My personal .02: I think we should consider branching 5.0 September 1st.
That gives us basically 12 weeks for folks to do their testing and for us
to stabilize anything that's flaky in circle or regressed in ASF CI.

WFM, if that means we branch there and anything not already merged has to
wait


On Mon, Apr 17, 2023 at 3:37 PM Josh McKenzie  wrote:

> it's (b) for me, and everything minus 21 and 15 is defining enough to
> warrant the branching and a checkpoint where testing can start
>
> Ok, I don't follow.
>
> There's three different ways I can read what you're saying here:
>
>1. "Everything we have targeting 5.x is substantial and we can branch
>when it's done", that'd mean 600+ open tickets, so it can't be that:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%205.x%20and%20resolution%20%3D%20unresolved
>2. "Everything we've *already merged today* targeting 5.x is
>substantial and we can branch now"... I don't think that's quite right?
>Since that'd put the release far too early after December '22.
>3. "Everything we expect to merge by August 1st, regardless of CEP-21
>and CEP-15, is substantial enough for us to cut a release then" - that's
>arguing for a feature-driven release rather than a train right?
>
> Sorry; I'm definitely not *trying* to be obtuse, I'm just having a hard
> time understanding how what the two of you are saying actually lines up.
>
> My personal .02: I think we should consider branching 5.0 September 1st.
> That gives us basically 12 weeks for folks to do their testing and for us
> to stabilize anything that's flaky in circle or regressed in ASF CI.
>
> If CEP-15 or CEP-21 land shortly after (early September), we can cross
> that bridge when the time comes.
>
> That's my hot take. We move to a train model and stick with it, and we
> start to get comfortable with cutting feature previews or snapshot alphas
> like we agreed to for earlier access to new stuff.
>
> On Mon, Apr 17, 2023, at 4:25 PM, Mick Semb Wever wrote:
>
>
> b.) Cut a 5.0 branch when the major release-defining element (maybe
> CEP-21?) merges to trunk, with the shared understanding (possibly what
> we're disagreeing about) that very little of what we need to test/de-risk
> is going to be inhibited by not cutting that branch earlier (and that
> certain testing efforts would be almost wholesale wasted if done
> beforehand).
>
>
>
> Yup, it's (b) for me, and everything minus 21 and 15 is defining enough to
> warrant the branching and a checkpoint where testing can start and not be
> wasted.  I understand that cep-21 changes a lot and that impacts testing,
> but I wholeheartedly trust testers to be taking this into consideration.
>
>
>

Re: [DISCUSS] Next release date

[Josh McKenzie]

> it's (b) for me, and everything minus 21 and 15 is defining enough to warrant 
> the branching and a checkpoint where testing can start
Ok, I don't follow.

There's three different ways I can read what you're saying here:
 1. "Everything we have targeting 5.x is substantial and we can branch when 
it's done", that'd mean 600+ open tickets, so it can't be that: 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%205.x%20and%20resolution%20%3D%20unresolved
 2. "Everything we've *already merged today* targeting 5.x is substantial and 
we can branch now"... I don't think that's quite right? Since that'd put the 
release far too early after December '22.
 3. "Everything we expect to merge by August 1st, regardless of CEP-21 and 
CEP-15, is substantial enough for us to cut a release then" - that's arguing 
for a feature-driven release rather than a train right?
Sorry; I'm definitely not *trying* to be obtuse, I'm just having a hard time 
understanding how what the two of you are saying actually lines up.

My personal .02: I think we should consider branching 5.0 September 1st. That 
gives us basically 12 weeks for folks to do their testing and for us to 
stabilize anything that's flaky in circle or regressed in ASF CI.

If CEP-15 or CEP-21 land shortly after (early September), we can cross that 
bridge when the time comes.

That's my hot take. We move to a train model and stick with it, and we start to 
get comfortable with cutting feature previews or snapshot alphas like we agreed 
to for earlier access to new stuff.

On Mon, Apr 17, 2023, at 4:25 PM, Mick Semb Wever wrote:
> 
>> b.) Cut a 5.0 branch when the major release-defining element (maybe CEP-21?) 
>> merges to trunk, with the shared understanding (possibly what we're 
>> disagreeing about) that very little of what we need to test/de-risk is going 
>> to be inhibited by not cutting that branch earlier (and that certain testing 
>> efforts would be almost wholesale wasted if done beforehand).
> 
> 
> Yup, it's (b) for me, and everything minus 21 and 15 is defining enough to 
> warrant the branching and a checkpoint where testing can start and not be 
> wasted.  I understand that cep-21 changes a lot and that impacts testing, but 
> I wholeheartedly trust testers to be taking this into consideration. 
> 

Re: [DISCUSS] Next release date

[Mick Semb Wever]

> b.) Cut a 5.0 branch when the major release-defining element (maybe
> CEP-21?) merges to trunk, with the shared understanding (possibly what
> we're disagreeing about) that very little of what we need to test/de-risk
> is going to be inhibited by not cutting that branch earlier (and that
> certain testing efforts would be almost wholesale wasted if done
> beforehand).
>

Yup, it's (b) for me, and everything minus 21 and 15 is defining enough to
warrant the branching and a checkpoint where testing can start and not be
wasted.  I understand that cep-21 changes a lot and that impacts testing,
but I wholeheartedly trust testers to be taking this into consideration.

Re: [DISCUSS] Next release date

[Caleb Rackliffe]

What I'm trying to propose is that we either...

a.) Pick the latest responsible (preserves our desired timeline for GA)
date to cut a 5.0 branch, and not let anything else in after, including
CEP-15/CEP-21.
b.) Cut a 5.0 branch when the major release-defining element (maybe
CEP-21?) merges to trunk, with the shared understanding (possibly what
we're disagreeing about) that very little of what we need to test/de-risk
is going to be inhibited by not cutting that branch earlier (and that
certain testing efforts would be almost wholesale wasted if done
beforehand).

i.e. Have one freeze/branch point. Pick a date and don't make exceptions,
or pick the feature and *potentially* adjust the date.

On Mon, Apr 17, 2023 at 2:07 PM Josh McKenzie  wrote:

> So to bring us back to the goals and alignment here:
>
> With the following intentions:
> - moving towards the goal of annual releases, with a cadence 12±3 months
> apart,
> - the branch to GA period being 2-3 months,
> - avoiding any type of freeze on trunk,
> - getting a release out by December's Summit,
> - freeing up folk to start QA (that makes sense to start) immediately
>
> So what I *think* falls out logically:
>
> 1. We branch cassandra-5.0 on August 1st
> 2. We expect an 8-12 week validation cycle which means GA Oct1-Nov1.
> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk
> invalidating stabilization and risk our 2023 GA date
> 3b. If we don't allow merge of CEP-15 / CEP-21 after branch, we risk
> needing a fast-follow release and don't have functional precedent for the
> snapshots we earlier agreed upon doing.
>
> Does that distill it and match everyone else's understanding?
>
> On Mon, Apr 17, 2023, at 2:20 PM, Mick Semb Wever wrote:
>
>
>
> On Mon, 17 Apr 2023 at 19:31, Caleb Rackliffe 
> wrote:
>
> ...or just cutting a 5.0 branch when CEP-21 is ready.
>
> There's nothing stopping us from testing JDK17 and TTL bits in trunk
> before that.
>
> On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe 
> wrote:
>
> > Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0
>
> For the record, I'm not convinced this is necessarily better than just
> cutting a cassandra-5.0 branch on 1 October.
>
>
>
> How else would this work without being akin to a feature freeze on trunk.
>
> We want (need) as much time as possible to test. We have no evidence that
> it will be quicker than 4.1, we have to create that evidence. Those folk
> that free up and are ready to get ahead and de-risk our testing efforts
> should be given a release branch to make their work easier and to give us
> that evidence in a more controlled manner so that we can plan better next
> time. Appreciate that there's one too many variables here, but I'm sticking
> up for the testing efforts here.
>
>
>

Re: [DISCUSS] Next release date

[Josh McKenzie]

I failed to address:
> - freeing up folk to start QA (that makes sense to start) immediately
I think there's a pre-freeze set of QA that makes sense to do and a 
post-freeze. What we decide on mergeability of large bodies of work around that 
branch date will inform what qualifies as a "freeze" in this regard.

On Mon, Apr 17, 2023, at 3:06 PM, Josh McKenzie wrote:
> So to bring us back to the goals and alignment here:
> 
>> With the following intentions:
>> - moving towards the goal of annual releases, with a cadence 12±3 months 
>> apart,
>> - the branch to GA period being 2-3 months,
>> - avoiding any type of freeze on trunk,
>> - getting a release out by December's Summit,
>> - freeing up folk to start QA (that makes sense to start) immediately
> So what I *think* falls out logically:
> 
> 1. We branch cassandra-5.0 on August 1st
> 2. We expect an 8-12 week validation cycle which means GA Oct1-Nov1.
> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk invalidating 
> stabilization and risk our 2023 GA date
> 3b. If we don't allow merge of CEP-15 / CEP-21 after branch, we risk needing 
> a fast-follow release and don't have functional precedent for the snapshots 
> we earlier agreed upon doing.
> 
> Does that distill it and match everyone else's understanding?
> 
> On Mon, Apr 17, 2023, at 2:20 PM, Mick Semb Wever wrote:
>> 
>> 
>> On Mon, 17 Apr 2023 at 19:31, Caleb Rackliffe  
>> wrote:
>>> ...or just cutting a 5.0 branch when CEP-21 is ready.
>>> 
>>> There's nothing stopping us from testing JDK17 and TTL bits in trunk before 
>>> that.
>>> 
>>> On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe  
>>> wrote:
 > Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0
 
 For the record, I'm not convinced this is necessarily better than just 
 cutting a cassandra-5.0 branch on 1 October.
>> 
>> 
>> How else would this work without being akin to a feature freeze on trunk.
>> 
>> We want (need) as much time as possible to test. We have no evidence that it 
>> will be quicker than 4.1, we have to create that evidence. Those folk that 
>> free up and are ready to get ahead and de-risk our testing efforts should be 
>> given a release branch to make their work easier and to give us that 
>> evidence in a more controlled manner so that we can plan better next time. 
>> Appreciate that there's one too many variables here, but I'm sticking up for 
>> the testing efforts here.
> 

Re: [DISCUSS] Next release date

[Josh McKenzie]

So to bring us back to the goals and alignment here:

> With the following intentions:
> - moving towards the goal of annual releases, with a cadence 12±3 months 
> apart,
> - the branch to GA period being 2-3 months,
> - avoiding any type of freeze on trunk,
> - getting a release out by December's Summit,
> - freeing up folk to start QA (that makes sense to start) immediately
So what I *think* falls out logically:

1. We branch cassandra-5.0 on August 1st
2. We expect an 8-12 week validation cycle which means GA Oct1-Nov1.
3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk invalidating 
stabilization and risk our 2023 GA date
3b. If we don't allow merge of CEP-15 / CEP-21 after branch, we risk needing a 
fast-follow release and don't have functional precedent for the snapshots we 
earlier agreed upon doing.

Does that distill it and match everyone else's understanding?

On Mon, Apr 17, 2023, at 2:20 PM, Mick Semb Wever wrote:
> 
> 
> On Mon, 17 Apr 2023 at 19:31, Caleb Rackliffe  
> wrote:
>> ...or just cutting a 5.0 branch when CEP-21 is ready.
>> 
>> There's nothing stopping us from testing JDK17 and TTL bits in trunk before 
>> that.
>> 
>> On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe  
>> wrote:
>>> > Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0
>>> 
>>> For the record, I'm not convinced this is necessarily better than just 
>>> cutting a cassandra-5.0 branch on 1 October.
> 
> 
> How else would this work without being akin to a feature freeze on trunk.
> 
> We want (need) as much time as possible to test. We have no evidence that it 
> will be quicker than 4.1, we have to create that evidence. Those folk that 
> free up and are ready to get ahead and de-risk our testing efforts should be 
> given a release branch to make their work easier and to give us that evidence 
> in a more controlled manner so that we can plan better next time. Appreciate 
> that there's one too many variables here, but I'm sticking up for the testing 
> efforts here.

Re: [DISCUSS] Next release date

[Mick Semb Wever]

On Mon, 17 Apr 2023 at 19:31, Caleb Rackliffe 
wrote:

> ...or just cutting a 5.0 branch when CEP-21 is ready.
>
> There's nothing stopping us from testing JDK17 and TTL bits in trunk
> before that.
>
> On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe 
> wrote:
>
>> > Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0
>>
>> For the record, I'm not convinced this is necessarily better than just
>> cutting a cassandra-5.0 branch on 1 October.
>>
>

How else would this work without being akin to a feature freeze on trunk.

We want (need) as much time as possible to test. We have no evidence that
it will be quicker than 4.1, we have to create that evidence. Those folk
that free up and are ready to get ahead and de-risk our testing efforts
should be given a release branch to make their work easier and to give us
that evidence in a more controlled manner so that we can plan better next
time. Appreciate that there's one too many variables here, but I'm sticking
up for the testing efforts here.

Re: [DISCUSS] Next release date

[Caleb Rackliffe]

...or just cutting a 5.0 branch when CEP-21 is ready.

There's nothing stopping us from testing JDK17 and TTL bits in trunk before
that.

On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe 
wrote:

> > Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0
>
> For the record, I'm not convinced this is necessarily better than just
> cutting a cassandra-5.0 branch on 1 October.
>
> On Mon, Apr 17, 2023 at 2:30 AM Mick Semb Wever  wrote:
>
>> 2. When CEP-15 lands we cut alpha1,
>>> 2a. The deadline is first week of October, anything not yet in
>>> cassandra-5.0 is not in 5.0,
>>> 2b. We expect a minimum two months of testing and beta+rc releases
>>> to get to GA.
>>>
>>> To clarify, is the intent here to say "The deadline for cutoff is 1st
>>> week of October for everything, including CEP-15"? Or is the intent to say
>>> "we don't cut alpha1 until CEP-15 lands"?
>>>
>>
>>
>> The former. The first week of October will be the full feature freeze on
>> the cassandra-5.0 branch.
>>
>>
>>

Re: [DISCUSS] Next release date

[Caleb Rackliffe]

> Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0

For the record, I'm not convinced this is necessarily better than just
cutting a cassandra-5.0 branch on 1 October.

On Mon, Apr 17, 2023 at 2:30 AM Mick Semb Wever  wrote:

> 2. When CEP-15 lands we cut alpha1,
>> 2a. The deadline is first week of October, anything not yet in
>> cassandra-5.0 is not in 5.0,
>> 2b. We expect a minimum two months of testing and beta+rc releases
>> to get to GA.
>>
>> To clarify, is the intent here to say "The deadline for cutoff is 1st
>> week of October for everything, including CEP-15"? Or is the intent to say
>> "we don't cut alpha1 until CEP-15 lands"?
>>
>
>
> The former. The first week of October will be the full feature freeze on
> the cassandra-5.0 branch.
>
>
>

Re: [DISCUSS] Next release date

[Mick Semb Wever]

>
> 2. When CEP-15 lands we cut alpha1,
> 2a. The deadline is first week of October, anything not yet in
> cassandra-5.0 is not in 5.0,
> 2b. We expect a minimum two months of testing and beta+rc releases
> to get to GA.
>
> To clarify, is the intent here to say "The deadline for cutoff is 1st week
> of October for everything, including CEP-15"? Or is the intent to say "we
> don't cut alpha1 until CEP-15 lands"?
>


The former. The first week of October will be the full feature freeze on
the cassandra-5.0 branch.

Re: [DISCUSS] Next release date

[Josh McKenzie]

> 2. When CEP-15 lands we cut alpha1,
> 2a. The deadline is first week of October, anything not yet in
> cassandra-5.0 is not in 5.0,
> 2b. We expect a minimum two months of testing and beta+rc releases
> to get to GA.
To clarify, is the intent here to say "The deadline for cutoff is 1st week of 
October for everything, including CEP-15"? Or is the intent to say "we don't 
cut alpha1 until CEP-15 lands"?

On Sun, Apr 16, 2023, at 7:11 PM, Mick Semb Wever wrote:
> >
> >> We have a lot of significant features that have or will land soon and our 
> >> experience suggests that those merges usually bring their set of 
> >> instabilities. The goal of the proposal was to make sure that we get rid 
> >> of them before TCM and Accord land to allow us to more easily identify the 
> >> root causes of problems.
> >
> >
> > Agree with Benjamin that testing in phases, i.e. separate periods of time, 
> > has positives that we can take advantage of.
> >
> 
> 
> Where did we land on this?
> 
> With the following intentions:
> - moving towards the goal of annual releases, with a cadence 12±3 months 
> apart,
> - the branch to GA period being 2-3 months,
> - avoiding any type of freeze on trunk,
> - getting a release out by December's Summit,
> - freeing up folk to start QA (that makes sense to start) immediately
> 
> ;I'm going to suggest the following…
> 
> 1. Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0,
> 1a. QA starts on cassandra-5.0,
> 1b. CEP-21 and CEP-15 are waivered to land in cassandra-5.0, and
> forward-merge to trunk,
> 
> 2. When CEP-15 lands we cut alpha1,
> 2a. The deadline is first week of October, anything not yet in
> cassandra-5.0 is not in 5.0,
> 2b. We expect a minimum two months of testing and beta+rc releases
> to get to GA.
> 
> 
> Additional notes,
> 1) "Once all CEPs" includes jdk17 and extending TTL tickets.
> 1) We ask folk to be considerate of what they commit in trunk wrt to
> the inbound CEP-21.
> 1a) There's an understanding of what needs to be re-tested after CEP-21.
> 2) The initial release may be beta1, we make that call at that time.
> 2a) features not complete can still be in 5.0 as experimental and not
> enabled by default.
> 2b) If CEP-15 lands Aug/Sept, then the earliest possible GA release
> date is in October.
> 
> I feel this proposal will give us evidence and help put us back on
> track for a release train model with a shorter QA2GA period, and
> aiming for a 5.1 release a bit earlier in the 2024 year (e.g. Q3).
> 
> If we agree on this proposal I will update our downloads page (ref
> German's thread).
> 

Re: [DISCUSS] Next release date

[Mick Semb Wever]

>
>> We have a lot of significant features that have or will land soon and our 
>> experience suggests that those merges usually bring their set of 
>> instabilities. The goal of the proposal was to make sure that we get rid of 
>> them before TCM and Accord land to allow us to more easily identify the root 
>> causes of problems.
>
>
> Agree with Benjamin that testing in phases, i.e. separate periods of time, 
> has positives that we can take advantage of.
>


Where did we land on this?

With the following intentions:
 - moving towards the goal of annual releases, with a cadence 12±3 months apart,
 - the branch to GA period being 2-3 months,
 - avoiding any type of freeze on trunk,
 - getting a release out by December's Summit,
 - freeing up folk to start QA (that makes sense to start) immediately

;I'm going to suggest the following…

 1. Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0,
1a. QA starts on cassandra-5.0,
1b. CEP-21 and CEP-15 are waivered to land in cassandra-5.0, and
forward-merge to trunk,

 2. When CEP-15 lands we cut alpha1,
2a. The deadline is first week of October, anything not yet in
cassandra-5.0 is not in 5.0,
2b. We expect a minimum two months of testing and beta+rc releases
to get to GA.


Additional notes,
 1) "Once all CEPs" includes jdk17 and extending TTL tickets.
 1) We ask folk to be considerate of what they commit in trunk wrt to
the inbound CEP-21.
 1a) There's an understanding of what needs to be re-tested after CEP-21.
 2) The initial release may be beta1, we make that call at that time.
 2a) features not complete can still be in 5.0 as experimental and not
enabled by default.
 2b) If CEP-15 lands Aug/Sept, then the earliest possible GA release
date is in October.

I feel this proposal will give us evidence and help put us back on
track for a release train model with a shorter QA2GA period, and
aiming for a 5.1 release a bit earlier in the 2024 year (e.g. Q3).

If we agree on this proposal I will update our downloads page (ref
German's thread).

Re: [EXTERNAL] [DISCUSS] Next release date

[Mick Semb Wever]

>
> I'd be happier with something concrete like the following expected release
> flow:
>
> 1) We freeze a branch
> 2) To hit RC, we need green circle + no regression on ASF (or green ASF in
> the future when stable)
> 3) We need N weeks in this frozen state for people to test it out
> 4) Once we have both 2 and 3, we RC and GA
>


Yeah, I was thinking (1) would include the beta1 release if we're already
green, i.e. meaning we'd skip (2), or alpha1 if not yet green.
3) would still hold, but would be N weeks from first beta to first rc.

That is, something like…

1) branch. if green cut beta1 else cut alpha1
  1a) when green then cut beta1
2) wait N weeks from beta1. if no blockers cut rc1
3) wait 2 weeks. if no blockers cut GA

As evident from both 4.0 and 4.1  the alpha to beta timeframe hurts, and
our Stable Trunk (and CI) efforts are to minimise/remove this.  That is,
this incentivises us to get on top of CI issues and flakies ahead of branch
time.


Is it too prescriptive to say "we'll be frozen on a branch for at least 8
> weeks so folks can test out the betas"? (I ask because I know I can get a
> little "structure-happy" at times).
>


6-8 weeks feels right, if we want to be prescriptive. And there needs to be
a sense of urgency when we make this call to action to downstream testers.
As a release manager I know that an error margin of two weeks is typical.

Re: [EXTERNAL] [DISCUSS] Next release date

[Josh McKenzie]

> in practice we wait and receive bug reports from downstream testing efforts. 
> Such testing isn't necessarily possible pre-commit, e.g. third-party and not 
> feasible to continuously run, nor appropriate to upstream/open-source.
> 
> We want GA releases to be production ready for any cluster at any scale. So I 
> guess in practice for us Stable Trunk != GA, but that's ok
I agree with this sentiment, and I also am uncomfortable with how vague this 
presently is. I'd be happier with something concrete like the following 
expected release flow:

1) We freeze a branch
2) To hit RC, we need green circle + no regression on ASF (or green ASF in the 
future when stable)
3) We need N weeks in this frozen state for people to test it out
4) Once we have both 2 and 3, we RC and GA

I definitely think there should be a time-boxed element of it but as far as I 
know we haven't really settled on that and it's pretty hand-wavy. Probably moot 
as in the past getting tests to green gave us enough calendar time that folks 
had plenty of time to test out the betas and RC's, but in a world where tests 
are stable, that shifts us to needing to set a minimum time on calendar to give 
folks time to test.

Is it too prescriptive to say "we'll be frozen on a branch for at least 8 weeks 
so folks can test out the betas"? (I ask because I know I can get a little 
"structure-happy" at times).


On Fri, Mar 31, 2023, at 9:17 AM, Mick Semb Wever wrote:
> 
>> We have a lot of significant features that have or will land soon and our 
>> experience suggests that those merges usually bring their set of 
>> instabilities. The goal of the proposal was to make sure that we get rid of 
>> them before TCM and Accord land to allow us to more easily identify the root 
>> causes of problems. 
>>> 
>> 
>>  
> Agree with Benjamin that testing in phases, i.e. separate periods of time, 
> has positives that we can take advantage of.
> 
> 
> 
>> a) do we have test failures on circle on trunk right now, and
>> b) do we have regressions on trunk on ASF CI compared to 4.1
>> 
>> Whether or not new features land near the cutoff date or not shouldn't 
>> impact the above right?
> 
> 
> I don't think it can be limited to the above. They are our minimum 
> requirements to getting to beta, to rc, and to GA. But in practice we wait 
> and receive bug reports from downstream testing efforts. Such testing isn't 
> necessarily possible pre-commit, e.g. third-party and not feasible to 
> continuously run, nor appropriate to upstream/open-source.
> 
> We want GA releases to be production ready for any cluster at any scale. So I 
> guess in practice for us Stable Trunk != GA, but that's ok – just being 
> honest to the ideal we are moving towards.
>  

Re: [EXTERNAL] [DISCUSS] Next release date

[Mick Semb Wever]

> We have a lot of significant features that have or will land soon and our
> experience suggests that those merges usually bring their set of
> instabilities. The goal of the proposal was to make sure that we get rid of
> them before TCM and Accord land to allow us to more easily identify the
> root causes of problems.




Agree with Benjamin that testing in phases, i.e. separate periods of time,
has positives that we can take advantage of.



a) do we have test failures on circle on trunk right now, and
> b) do we have regressions on trunk on ASF CI compared to 4.1
>
> Whether or not new features land near the cutoff date or not shouldn't
> impact the above right?
>


I don't think it can be limited to the above. They are our minimum
requirements to getting to beta, to rc, and to GA. But in practice we wait
and receive bug reports from downstream testing efforts. Such testing isn't
necessarily possible pre-commit, e.g. third-party and not feasible to
continuously run, nor appropriate to upstream/open-source.

We want GA releases to be production ready for any cluster at any scale. So
I guess in practice for us Stable Trunk != GA, but that's ok – just being
honest to the ideal we are moving towards.

Re: [EXTERNAL] [DISCUSS] Next release date

[J. D. Jordan]

That was my understanding as well.On Mar 30, 2023, at 11:21 AM, Josh McKenzie  wrote:So to confirm, let's make sure we all agree on the definition of "stabilize".Using the definition as "green run of all tests on circleci, no regressions on ASF CI" that we used to get 4.1 out the door, and combined with the metric of "feature branches don't merge until their CI is green on at least CircleCI and don't regress on ASF CI"... that boils down to:a) do we have test failures on circle on trunk right now, andb) do we have regressions on trunk on ASF CI compared to 4.1Whether or not new features land near the cutoff date or not shouldn't impact the above right?I'm receptive to another definition of "stabilize", having a time-boxed on calendar window for people to run a beta or RC, or whatever. But my understanding is that the above was our general consensus in the 4.1 window.I definitely could be wrong. :)On Thu, Mar 30, 2023, at 5:22 AM, Benjamin Lerer wrote:but otherwise I don't recall anything that we could take as an indicator
 that a next release would take a comparable amount of time to 4.1?Do we have any indicator that proves that it will take less time? We never managed to do a release in 2 or 3 months so far. Until we have actually proven that we could do it, I simply prefer assuming that we cannot and plan for the worst.We have a lot of significant features that have or will land soon and our experience suggests that those merges usually bring their set of instabilities. The goal of the proposal was to make sure that we get rid of them before TCM and Accord land to allow us to more easily identify the root causes of problems. Gaining time on the overall stabilization process. I am fine with people not liking the proposal. Nevertheless, simply hoping that it will take us 2 months to stabilize the release seems pretty optimistic to me. Do people have another plan in mind for ensuring a short stabilization period?Le lun. 27 mars 2023 à 09:20, Henrik Ingo  a écrit :Not so fast...There's certainly value in spending that time stabilizing the already done features. It's valuable triaging information to say this used to work before CEP-21 and only broke after it.That said, having a very long freeze of trunk, or alternatively having a very long lived 5.0 branch that is waiting for Accord and diverging with a trunk that is not frozen... are both undesirable options. (A month or two could IMO be discussed though.) So I agree with the concern from that point of view, I just don't agree that having one batch of big features in stabilization period is zero value.henrikOn Fri, Mar 24, 2023 at 5:23 PM Jeremiah D Jordan  wrote:Given the fundamental change to how cluster operations work coming from CEP-21, I’m not sure what freezing early for “extra QA time” really buys us?  I wouldn’t trust any multi-node QA done pre commit.What “stabilizing” do we expect to be doing during this time?  How much of it do we just have to do again after those things merge?  I for one do not like to have release branches cut months before their expected release.  It just adds extra merge forward and “where should this go” questions/overhead.  It could make sense to me to branch branch when CEP-21 merges and only let in CEP-15 after that.  CEP-15 is mostly “net new stuff” and not “changes to existing stuff” from my understanding?  So no QA effort wasted if it is done before it merges.-JeremiahOn Mar 24, 2023, at 9:38 AM, Josh McKenzie  wrote:I would like to propose a partial freeze of 5.0 in JuneMy .02:+1 to:* partial freeze on an agreed upon date w/agreed upon other things that can optionally go in after* setting a hard limit on when we ship from that frozen branch regardless of whether the features land or not-1 to:* ever feature freezing trunk again. :)I worry about the labor involved with having very large work like this target a frozen branch and then also needing to pull it up to trunk. That doesn't sound fun.If we resurrected the discussion about cutting alpha snapshots from trunk, would that change people's perspectives on the weight of this current decision? We'd probably also have to re-open pandora's box talking about the solidity of our API's on trunk as well if we positioned those alphas as being stable enough to start prototyping and/or building future applications against.On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote:I am +1 on a 5.0 branch freeze.Kind Regards,BrandonOn Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer  wrote: Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?>>> I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and allowing only CEP-15 and 21 + bug fixes there.> Le ven. 24 mars 2023 à 13:55, Paulo Motta  a écrit : >  I would like to propose a partial freeze of 5.0 in June. Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I agr

Re: [EXTERNAL] [DISCUSS] Next release date

[Josh McKenzie]

So to confirm, let's make sure we all agree on the definition of "stabilize".

Using the definition as "green run of all tests on circleci, no regressions on 
ASF CI" that we used to get 4.1 out the door, and combined with the metric of 
"feature branches don't merge until their CI is green on at least CircleCI and 
don't regress on ASF CI"... that boils down to:

a) do we have test failures on circle on trunk right now, and
b) do we have regressions on trunk on ASF CI compared to 4.1

Whether or not new features land near the cutoff date or not shouldn't impact 
the above right?

I'm receptive to another definition of "stabilize", having a time-boxed on 
calendar window for people to run a beta or RC, or whatever. But my 
understanding is that the above was our general consensus in the 4.1 window.

I definitely could be wrong. :)

On Thu, Mar 30, 2023, at 5:22 AM, Benjamin Lerer wrote:
>> but otherwise I don't recall anything that we could take as an indicator 
>> that a next release would take a comparable amount of time to 4.1?
> 
> Do we have any indicator that proves that it will take less time? We never 
> managed to do a release in 2 or 3 months so far. Until we have actually 
> proven that we could do it, I simply prefer assuming that we cannot and plan 
> for the worst.
> 
> We have a lot of significant features that have or will land soon and our 
> experience suggests that those merges usually bring their set of 
> instabilities. The goal of the proposal was to make sure that we get rid of 
> them before TCM and Accord land to allow us to more easily identify the root 
> causes of problems. Gaining time on the overall stabilization process. I am 
> fine with people not liking the proposal. Nevertheless, simply hoping that it 
> will take us 2 months to stabilize the release seems pretty optimistic to me. 
> Do people have another plan in mind for ensuring a short stabilization period?
> 
> 
> Le lun. 27 mars 2023 à 09:20, Henrik Ingo  a écrit :
>> Not so fast...
>> 
>> There's certainly value in spending that time stabilizing the already done 
>> features. It's valuable triaging information to say this used to work before 
>> CEP-21 and only broke after it.
>> 
>> That said, having a very long freeze of trunk, or alternatively having a 
>> very long lived 5.0 branch that is waiting for Accord and diverging with a 
>> trunk that is not frozen... are both undesirable options. (A month or two 
>> could IMO be discussed though.) So I agree with the concern from that point 
>> of view, I just don't agree that having one batch of big features in 
>> stabilization period is zero value.
>> 
>> 
>> henrik
>> 
>> 
>> 
>> On Fri, Mar 24, 2023 at 5:23 PM Jeremiah D Jordan 
>>  wrote:
>>> Given the fundamental change to how cluster operations work coming from 
>>> CEP-21, I’m not sure what freezing early for “extra QA time” really buys 
>>> us?  I wouldn’t trust any multi-node QA done pre commit.
>>> What “stabilizing” do we expect to be doing during this time?  How much of 
>>> it do we just have to do again after those things merge?  I for one do not 
>>> like to have release branches cut months before their expected release.  It 
>>> just adds extra merge forward and “where should this go” 
>>> questions/overhead.  It could make sense to me to branch branch when CEP-21 
>>> merges and only let in CEP-15 after that.  CEP-15 is mostly “net new stuff” 
>>> and not “changes to existing stuff” from my understanding?  So no QA effort 
>>> wasted if it is done before it merges.
>>> 
>>> -Jeremiah
>>> 
 On Mar 24, 2023, at 9:38 AM, Josh McKenzie  wrote:
 
> I would like to propose a partial freeze of 5.0 in June
 My .02:
 +1 to:
 * partial freeze on an agreed upon date w/agreed upon other things that 
 can optionally go in after
 * setting a hard limit on when we ship from that frozen branch regardless 
 of whether the features land or not
 
 -1 to:
 * ever feature freezing trunk again. :)
 
 I worry about the labor involved with having very large work like this 
 target a frozen branch and then also needing to pull it up to trunk. That 
 doesn't sound fun.
 
 If we resurrected the discussion about cutting alpha snapshots from trunk, 
 would that change people's perspectives on the weight of this current 
 decision? We'd probably also have to re-open pandora's box talking about 
 the solidity of our API's on trunk as well if we positioned those alphas 
 as being stable enough to start prototyping and/or building future 
 applications against.
 
 On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote:
> I am +1 on a 5.0 branch freeze.
> 
> Kind Regards,
> Brandon
> 
> On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer  wrote:
> >>
> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
> >
> >
> > I was thinking of a cassandra-5.0 branch freeze. So branching 

Re: [EXTERNAL] [DISCUSS] Next release date

[Benjamin Lerer]

>
> but otherwise I don't recall anything that we could take as an indicator
> that a next release would take a comparable amount of time to 4.1?


Do we have any indicator that proves that it will take less time? We never
managed to do a release in 2 or 3 months so far. Until we have actually
proven that we could do it, I simply prefer assuming that we cannot and
plan for the worst.
We have a lot of significant features that have or will land soon and our
experience suggests that those merges usually bring their set of
instabilities. The goal of the proposal was to make sure that we get rid of
them before TCM and Accord land to allow us to more easily identify the
root causes of problems. Gaining time on the overall stabilization process.
I am fine with people not liking the proposal. Nevertheless, simply hoping
that it will take us 2 months to stabilize the release seems pretty
optimistic to me. Do people have another plan in mind for ensuring a short
stabilization period?


Le lun. 27 mars 2023 à 09:20, Henrik Ingo  a
écrit :

> Not so fast...
>
> There's certainly value in spending that time stabilizing the already done
> features. It's valuable triaging information to say this used to work
> before CEP-21 and only broke after it.
>
> That said, having a very long freeze of trunk, or alternatively having a
> very long lived 5.0 branch that is waiting for Accord and diverging with a
> trunk that is not frozen... are both undesirable options. (A month or two
> could IMO be discussed though.) So I agree with the concern from that point
> of view, I just don't agree that having one batch of big features in
> stabilization period is zero value.
>
>
> henrik
>
>
>
> On Fri, Mar 24, 2023 at 5:23 PM Jeremiah D Jordan <
> jeremiah.jor...@gmail.com> wrote:
>
>> Given the fundamental change to how cluster operations work coming from
>> CEP-21, I’m not sure what freezing early for “extra QA time” really buys
>> us?  I wouldn’t trust any multi-node QA done pre commit.
>> What “stabilizing” do we expect to be doing during this time?  How much
>> of it do we just have to do again after those things merge?  I for one do
>> not like to have release branches cut months before their expected
>> release.  It just adds extra merge forward and “where should this go”
>> questions/overhead.  It could make sense to me to branch branch when CEP-21
>> merges and only let in CEP-15 after that.  CEP-15 is mostly “net new stuff”
>> and not “changes to existing stuff” from my understanding?  So no QA effort
>> wasted if it is done before it merges.
>>
>> -Jeremiah
>>
>> On Mar 24, 2023, at 9:38 AM, Josh McKenzie  wrote:
>>
>> I would like to propose a partial freeze of 5.0 in June
>>
>> My .02:
>> +1 to:
>> * partial freeze on an agreed upon date w/agreed upon other things that
>> can optionally go in after
>> * setting a hard limit on when we ship from that frozen branch regardless
>> of whether the features land or not
>>
>> -1 to:
>> * ever feature freezing trunk again. :)
>>
>> I worry about the labor involved with having very large work like this
>> target a frozen branch and then also needing to pull it up to trunk. That
>> doesn't sound fun.
>>
>> If we resurrected the discussion about cutting alpha snapshots from
>> trunk, would that change people's perspectives on the weight of this
>> current decision? We'd probably also have to re-open pandora's box talking
>> about the solidity of our API's on trunk as well if we positioned those
>> alphas as being stable enough to start prototyping and/or building future
>> applications against.
>>
>> On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote:
>>
>> I am +1 on a 5.0 branch freeze.
>>
>> Kind Regards,
>> Brandon
>>
>> On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer  wrote:
>> >>
>> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
>> >
>> >
>> > I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and
>> allowing only CEP-15 and 21 + bug fixes there.
>> > Le ven. 24 mars 2023 à 13:55, Paulo Motta  a
>> écrit :
>> >>
>> >> >  I would like to propose a partial freeze of 5.0 in June.
>> >>
>> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I
>> agree with a branch freeze, but not with trunk freeze.
>> >>
>> >> I might work on small features after June and would be happy to delay
>> releasing these on 5.0+, but delaying merge to trunk until 5.0 is released
>> could be disruptive to contributors workflows and I would prefer to avoid
>> that if possible.
>> >>
>> >> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever 
>> wrote:
>> >>>
>> >>>
>>  I would like to propose a partial freeze of 5.0 in June.
>> 
>>  …
>> 
>>  This partial freeze will be valid for every new feature except
>> CEP-21 and CEP-15.
>> >>>
>> >>>
>> >>>
>> >>> +1
>> >>>
>> >>> Thanks for summarising the thread this way Benjamin. This addresses
>> my two main concerns: letting the branch/release date slip too much into
>> the unknown, squeez

Re: [EXTERNAL] [DISCUSS] Next release date

[Henrik Ingo]

Not so fast...

There's certainly value in spending that time stabilizing the already done
features. It's valuable triaging information to say this used to work
before CEP-21 and only broke after it.

That said, having a very long freeze of trunk, or alternatively having a
very long lived 5.0 branch that is waiting for Accord and diverging with a
trunk that is not frozen... are both undesirable options. (A month or two
could IMO be discussed though.) So I agree with the concern from that point
of view, I just don't agree that having one batch of big features in
stabilization period is zero value.


henrik



On Fri, Mar 24, 2023 at 5:23 PM Jeremiah D Jordan 
wrote:

> Given the fundamental change to how cluster operations work coming from
> CEP-21, I’m not sure what freezing early for “extra QA time” really buys
> us?  I wouldn’t trust any multi-node QA done pre commit.
> What “stabilizing” do we expect to be doing during this time?  How much of
> it do we just have to do again after those things merge?  I for one do not
> like to have release branches cut months before their expected release.  It
> just adds extra merge forward and “where should this go”
> questions/overhead.  It could make sense to me to branch branch when CEP-21
> merges and only let in CEP-15 after that.  CEP-15 is mostly “net new stuff”
> and not “changes to existing stuff” from my understanding?  So no QA effort
> wasted if it is done before it merges.
>
> -Jeremiah
>
> On Mar 24, 2023, at 9:38 AM, Josh McKenzie  wrote:
>
> I would like to propose a partial freeze of 5.0 in June
>
> My .02:
> +1 to:
> * partial freeze on an agreed upon date w/agreed upon other things that
> can optionally go in after
> * setting a hard limit on when we ship from that frozen branch regardless
> of whether the features land or not
>
> -1 to:
> * ever feature freezing trunk again. :)
>
> I worry about the labor involved with having very large work like this
> target a frozen branch and then also needing to pull it up to trunk. That
> doesn't sound fun.
>
> If we resurrected the discussion about cutting alpha snapshots from trunk,
> would that change people's perspectives on the weight of this current
> decision? We'd probably also have to re-open pandora's box talking about
> the solidity of our API's on trunk as well if we positioned those alphas as
> being stable enough to start prototyping and/or building future
> applications against.
>
> On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote:
>
> I am +1 on a 5.0 branch freeze.
>
> Kind Regards,
> Brandon
>
> On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer  wrote:
> >>
> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
> >
> >
> > I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and
> allowing only CEP-15 and 21 + bug fixes there.
> > Le ven. 24 mars 2023 à 13:55, Paulo Motta  a
> écrit :
> >>
> >> >  I would like to propose a partial freeze of 5.0 in June.
> >>
> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I
> agree with a branch freeze, but not with trunk freeze.
> >>
> >> I might work on small features after June and would be happy to delay
> releasing these on 5.0+, but delaying merge to trunk until 5.0 is released
> could be disruptive to contributors workflows and I would prefer to avoid
> that if possible.
> >>
> >> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever  wrote:
> >>>
> >>>
>  I would like to propose a partial freeze of 5.0 in June.
> 
>  …
> 
>  This partial freeze will be valid for every new feature except CEP-21
> and CEP-15.
> >>>
> >>>
> >>>
> >>> +1
> >>>
> >>> Thanks for summarising the thread this way Benjamin. This addresses my
> two main concerns: letting the branch/release date slip too much into the
> unknown, squeezing GA QA efforts, while putting in place exceptional
> waivers for CEP-21 and CEP-15.
> >>>
> >>> I hope that in the future we will be more willing to commit to the
> release train model: less concerned about "what the next release contains";
> more comfortable letting big features land where they land. But this is
> opinion and discussion for another day… possibly looping back to the
> discussion on preview releases…
> >>>
> >>>
> >>> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21)
> landing in trunk?
> >>>
> >>>
>
>
>

-- 

Henrik Ingo

c. +358 40 569 7354

w. www.datastax.com

  
  

Re: [EXTERNAL] [DISCUSS] Next release date

[Josh McKenzie]

> We had far less features in 4.1 and it took us 6 months to release.
Definitely don't want to derail discussion but I could use some clarity. My 
current understanding is that the majority of our delay on 4.1 stabilization 
was due to ASF CI not being stable and switching to also accepting a 
combination of "green circle + no regressions on ASF compared to prior 
branches" unstuck us. I know there was one JIRA that had a pretty long tail 
(think it was streaming, metrics updating, contention timing out related...?) 
but otherwise I don't recall anything that we could take as an indicator that a 
next release would take a comparable amount of time to 4.1?


On Fri, Mar 24, 2023, at 2:56 PM, Caleb Rackliffe wrote:
> > That does not mean that the code should not be stabilized before the 
> > release. We had far less features in 4.1 and it took us 6 months to 
> > release. Accepting more features until August will probably result in 
> > extending the time needed to stabilize the release.
> 
> I think what I'm trying to get at is that CEP-21/TCM is almost certainly the 
> most invasive piece of work that will be in the release. This probably 
> means...
> 
> 1.) "Stabilization" work for anything it touches before it merges will be of 
> limited value.
> 2.) No matter what else goes in before it merges, it will probably be the 
> bottleneck for stabilizing the release.
> 
> If we want to cut a release after TCM merges, let's cut a 5.0 branch, 
> stabilize it, and let SAI, Accord, et al. merge to trunk and appear in the 
> next release. If SAI or Accord are ready at roughly the same time, having 
> already been based on TCM in their feature branches and extremely well-vetted 
> (Harry, performance testing, simulator exposure), we can have the discussion 
> about merging them and then cutting a release branch.
> 
> On Fri, Mar 24, 2023 at 1:39 PM Benjamin Lerer  wrote:
>>> SAI, Accord, UCS, and DDM are all features that can be pretty safely 
>>> disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk 
>>> those things much more easily before they merge.
>> 
>> That does not mean that the code should not be stabilized before the 
>> release. We had far less features in 4.1 and it took us 6 months to release. 
>> Accepting more features until August will probably result in extending the 
>> time needed to stabilize the release.
>> 
>>> I worry about the labor involved with having very large work like this 
>>> target a frozen branch and then also needing to pull it up to trunk. That 
>>> doesn't sound fun.
>> I am not sure I understand the issue of merging the work in a frozen branch. 
>> Should it not facilitate the work if the branch stops changing heavily? 
>> Regarding trunk, if most of us focus on stabilizing the 5.0 branch or on 
>> CEP-15 and 21 I do not think that it will change so much. Am I missing 
>> something?
>> 
>> Le ven. 24 mars 2023 à 19:16, Caleb Rackliffe  a 
>> écrit :
>>> > I worry about the labor involved with having very large work like this 
>>> > target a frozen branch and then also needing to pull it up to trunk. That 
>>> > doesn't sound fun.
>>> 
>>> > I for one do not like to have release branches cut months before their 
>>> > expected release.
>>> 
>>> > CEP-15 is mostly “net new stuff” and not “changes to existing stuff” from 
>>> > my understanding?
>>> 
>>> Yes, yes, and yes. Agree w/ JD here. If we want CEP-21 to make it into 5.0, 
>>> I'd oppose freezing a 5.0 branch for QA until it merges.
>>> 
>>> SAI, Accord, UCS, and DDM are all features that can be pretty safely 
>>> disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk 
>>> those things much more easily before they merge.
>>> 
>>> To try to address Mick's question, assuming we have Accord depending on 
>>> TCM, I'm not sure how closely it can follow TCM in merging. We've been 
>>> talking about this In another thread: "[DISCUSS] cep-15-accord, cep-21-tcm, 
>>> and trunk", but trying to rebase cep-15-accord on cep-21-tcm is probably 
>>> the easiest way to minimize that window...
>>> 
>>> On Fri, Mar 24, 2023 at 10:41 AM Benjamin Lerer  wrote:
> I’m not sure what freezing early for “extra QA time” really buys us?
 
 Tries, SAI, UCS, extended TTLs, Java 17, Dynamic Data Masking... all those 
 changes potentially introduce their set of issues/flakiness or other 
 problems. The freeze will allow us to find those early and facilitate the 
 integration of CEP 21 and 15 in my opinion. 
 
 Le ven. 24 mars 2023 à 16:23, Jeremiah D Jordan 
  a écrit :
> Given the fundamental change to how cluster operations work coming from 
> CEP-21, I’m not sure what freezing early for “extra QA time” really buys 
> us?  I wouldn’t trust any multi-node QA done pre commit.
> What “stabilizing” do we expect to be doing during this time?  How much 
> of it do we just have to do again after those things merge?  I for one do 
> not like to have release branch

Re: [EXTERNAL] [DISCUSS] Next release date

[Caleb Rackliffe]

> That does not mean that the code should not be stabilized before the
release. We had far less features in 4.1 and it took us 6 months to
release. Accepting more features until August will probably result in
extending the time needed to stabilize the release.

I think what I'm trying to get at is that CEP-21/TCM is almost certainly
the most invasive piece of work that will be in the release. This
probably means...

1.) "Stabilization" work for anything it touches before it merges will be
of limited value.
2.) No matter what else goes in before it merges, it will probably be the
bottleneck for stabilizing the release.

If we want to cut a release after TCM merges, let's cut a 5.0 branch,
stabilize it, and let SAI, Accord, et al. merge to trunk and appear in the
next release. If SAI or Accord are ready at roughly the same time, having
already been based on TCM in their feature branches and extremely
well-vetted (Harry, performance testing, simulator exposure), we can have
the discussion about merging them and then cutting a release branch.

On Fri, Mar 24, 2023 at 1:39 PM Benjamin Lerer  wrote:

> SAI, Accord, UCS, and DDM are all features that can be pretty safely
>> disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk
>> those things much more easily before they merge.
>
>
> That does not mean that the code should not be stabilized before the
> release. We had far less features in 4.1 and it took us 6 months to
> release. Accepting more features until August will probably result in
> extending the time needed to stabilize the release.
>
> I worry about the labor involved with having very large work like this
>> target a frozen branch and then also needing to pull it up to trunk. That
>> doesn't sound fun.
>>
> I am not sure I understand the issue of merging the work in a frozen
> branch. Should it not facilitate the work if the branch stops changing
> heavily? Regarding trunk, if most of us focus on stabilizing the 5.0 branch
> or on CEP-15 and 21 I do not think that it will change so much. Am I
> missing something?
>
> Le ven. 24 mars 2023 à 19:16, Caleb Rackliffe 
> a écrit :
>
>> > I worry about the labor involved with having very large work like this
>> target a frozen branch and then also needing to pull it up to trunk. That
>> doesn't sound fun.
>>
>> > I for one do not like to have release branches cut months before their
>> expected release.
>>
>> > CEP-15 is mostly “net new stuff” and not “changes to existing stuff”
>> from my understanding?
>>
>> Yes, yes, and yes. Agree w/ JD here. If we want CEP-21 to make it into
>> 5.0, I'd oppose freezing a 5.0 branch for QA until it merges.
>>
>> SAI, Accord, UCS, and DDM are all features that can be pretty safely
>> disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk
>> those things much more easily before they merge.
>>
>> To try to address Mick's question, assuming we have Accord depending on
>> TCM, I'm not sure how closely it can follow TCM in merging. We've been
>> talking about this In another thread: "[DISCUSS] cep-15-accord,
>> cep-21-tcm, and trunk", but trying to rebase cep-15-accord on cep-21-tcm
>> is probably the easiest way to minimize that window...
>>
>> On Fri, Mar 24, 2023 at 10:41 AM Benjamin Lerer 
>> wrote:
>>
>>> I’m not sure what freezing early for “extra QA time” really buys us?
>>>
>>>
>>> Tries, SAI, UCS, extended TTLs, Java 17, Dynamic Data Masking... all
>>> those changes potentially introduce their set of issues/flakiness or other
>>> problems. The freeze will allow us to find those early and facilitate the
>>> integration of CEP 21 and 15 in my opinion.
>>>
>>> Le ven. 24 mars 2023 à 16:23, Jeremiah D Jordan <
>>> jeremiah.jor...@gmail.com> a écrit :
>>>
 Given the fundamental change to how cluster operations work coming from
 CEP-21, I’m not sure what freezing early for “extra QA time” really buys
 us?  I wouldn’t trust any multi-node QA done pre commit.
 What “stabilizing” do we expect to be doing during this time?  How much
 of it do we just have to do again after those things merge?  I for one do
 not like to have release branches cut months before their expected
 release.  It just adds extra merge forward and “where should this go”
 questions/overhead.  It could make sense to me to branch branch when CEP-21
 merges and only let in CEP-15 after that.  CEP-15 is mostly “net new stuff”
 and not “changes to existing stuff” from my understanding?  So no QA effort
 wasted if it is done before it merges.

 -Jeremiah

 On Mar 24, 2023, at 9:38 AM, Josh McKenzie 
 wrote:

 I would like to propose a partial freeze of 5.0 in June

 My .02:
 +1 to:
 * partial freeze on an agreed upon date w/agreed upon other things that
 can optionally go in after
 * setting a hard limit on when we ship from that frozen branch
 regardless of whether the features land or not

 -1 to:
 * ever feature fr

Re: [EXTERNAL] [DISCUSS] Next release date

[Benjamin Lerer]

>
> SAI, Accord, UCS, and DDM are all features that can be pretty safely
> disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk
> those things much more easily before they merge.


That does not mean that the code should not be stabilized before the
release. We had far less features in 4.1 and it took us 6 months to
release. Accepting more features until August will probably result in
extending the time needed to stabilize the release.

I worry about the labor involved with having very large work like this
> target a frozen branch and then also needing to pull it up to trunk. That
> doesn't sound fun.
>
I am not sure I understand the issue of merging the work in a frozen
branch. Should it not facilitate the work if the branch stops changing
heavily? Regarding trunk, if most of us focus on stabilizing the 5.0 branch
or on CEP-15 and 21 I do not think that it will change so much. Am I
missing something?

Le ven. 24 mars 2023 à 19:16, Caleb Rackliffe  a
écrit :

> > I worry about the labor involved with having very large work like this
> target a frozen branch and then also needing to pull it up to trunk. That
> doesn't sound fun.
>
> > I for one do not like to have release branches cut months before their
> expected release.
>
> > CEP-15 is mostly “net new stuff” and not “changes to existing stuff”
> from my understanding?
>
> Yes, yes, and yes. Agree w/ JD here. If we want CEP-21 to make it into
> 5.0, I'd oppose freezing a 5.0 branch for QA until it merges.
>
> SAI, Accord, UCS, and DDM are all features that can be pretty safely
> disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk
> those things much more easily before they merge.
>
> To try to address Mick's question, assuming we have Accord depending on
> TCM, I'm not sure how closely it can follow TCM in merging. We've been
> talking about this In another thread: "[DISCUSS] cep-15-accord,
> cep-21-tcm, and trunk", but trying to rebase cep-15-accord on cep-21-tcm
> is probably the easiest way to minimize that window...
>
> On Fri, Mar 24, 2023 at 10:41 AM Benjamin Lerer  wrote:
>
>> I’m not sure what freezing early for “extra QA time” really buys us?
>>
>>
>> Tries, SAI, UCS, extended TTLs, Java 17, Dynamic Data Masking... all
>> those changes potentially introduce their set of issues/flakiness or other
>> problems. The freeze will allow us to find those early and facilitate the
>> integration of CEP 21 and 15 in my opinion.
>>
>> Le ven. 24 mars 2023 à 16:23, Jeremiah D Jordan <
>> jeremiah.jor...@gmail.com> a écrit :
>>
>>> Given the fundamental change to how cluster operations work coming from
>>> CEP-21, I’m not sure what freezing early for “extra QA time” really buys
>>> us?  I wouldn’t trust any multi-node QA done pre commit.
>>> What “stabilizing” do we expect to be doing during this time?  How much
>>> of it do we just have to do again after those things merge?  I for one do
>>> not like to have release branches cut months before their expected
>>> release.  It just adds extra merge forward and “where should this go”
>>> questions/overhead.  It could make sense to me to branch branch when CEP-21
>>> merges and only let in CEP-15 after that.  CEP-15 is mostly “net new stuff”
>>> and not “changes to existing stuff” from my understanding?  So no QA effort
>>> wasted if it is done before it merges.
>>>
>>> -Jeremiah
>>>
>>> On Mar 24, 2023, at 9:38 AM, Josh McKenzie  wrote:
>>>
>>> I would like to propose a partial freeze of 5.0 in June
>>>
>>> My .02:
>>> +1 to:
>>> * partial freeze on an agreed upon date w/agreed upon other things that
>>> can optionally go in after
>>> * setting a hard limit on when we ship from that frozen branch
>>> regardless of whether the features land or not
>>>
>>> -1 to:
>>> * ever feature freezing trunk again. :)
>>>
>>> I worry about the labor involved with having very large work like this
>>> target a frozen branch and then also needing to pull it up to trunk. That
>>> doesn't sound fun.
>>>
>>> If we resurrected the discussion about cutting alpha snapshots from
>>> trunk, would that change people's perspectives on the weight of this
>>> current decision? We'd probably also have to re-open pandora's box talking
>>> about the solidity of our API's on trunk as well if we positioned those
>>> alphas as being stable enough to start prototyping and/or building future
>>> applications against.
>>>
>>> On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote:
>>>
>>> I am +1 on a 5.0 branch freeze.
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>> On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer 
>>> wrote:
>>> >>
>>> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
>>> >
>>> >
>>> > I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and
>>> allowing only CEP-15 and 21 + bug fixes there.
>>> > Le ven. 24 mars 2023 à 13:55, Paulo Motta 
>>> a écrit :
>>> >>
>>> >> >  I would like to propose a partial freeze of 5.0 in June.
>>> >>
>>> >> Would that be a trunk free

Re: [EXTERNAL] [DISCUSS] Next release date

[Caleb Rackliffe]

> I worry about the labor involved with having very large work like this
target a frozen branch and then also needing to pull it up to trunk. That
doesn't sound fun.

> I for one do not like to have release branches cut months before their
expected release.

> CEP-15 is mostly “net new stuff” and not “changes to existing stuff” from
my understanding?

Yes, yes, and yes. Agree w/ JD here. If we want CEP-21 to make it into 5.0,
I'd oppose freezing a 5.0 branch for QA until it merges.

SAI, Accord, UCS, and DDM are all features that can be pretty safely
disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk
those things much more easily before they merge.

To try to address Mick's question, assuming we have Accord depending on
TCM, I'm not sure how closely it can follow TCM in merging. We've been
talking about this In another thread: "[DISCUSS] cep-15-accord, cep-21-tcm,
and trunk", but trying to rebase cep-15-accord on cep-21-tcm is probably
the easiest way to minimize that window...

On Fri, Mar 24, 2023 at 10:41 AM Benjamin Lerer  wrote:

> I’m not sure what freezing early for “extra QA time” really buys us?
>
>
> Tries, SAI, UCS, extended TTLs, Java 17, Dynamic Data Masking... all those
> changes potentially introduce their set of issues/flakiness or other
> problems. The freeze will allow us to find those early and facilitate the
> integration of CEP 21 and 15 in my opinion.
>
> Le ven. 24 mars 2023 à 16:23, Jeremiah D Jordan 
> a écrit :
>
>> Given the fundamental change to how cluster operations work coming from
>> CEP-21, I’m not sure what freezing early for “extra QA time” really buys
>> us?  I wouldn’t trust any multi-node QA done pre commit.
>> What “stabilizing” do we expect to be doing during this time?  How much
>> of it do we just have to do again after those things merge?  I for one do
>> not like to have release branches cut months before their expected
>> release.  It just adds extra merge forward and “where should this go”
>> questions/overhead.  It could make sense to me to branch branch when CEP-21
>> merges and only let in CEP-15 after that.  CEP-15 is mostly “net new stuff”
>> and not “changes to existing stuff” from my understanding?  So no QA effort
>> wasted if it is done before it merges.
>>
>> -Jeremiah
>>
>> On Mar 24, 2023, at 9:38 AM, Josh McKenzie  wrote:
>>
>> I would like to propose a partial freeze of 5.0 in June
>>
>> My .02:
>> +1 to:
>> * partial freeze on an agreed upon date w/agreed upon other things that
>> can optionally go in after
>> * setting a hard limit on when we ship from that frozen branch regardless
>> of whether the features land or not
>>
>> -1 to:
>> * ever feature freezing trunk again. :)
>>
>> I worry about the labor involved with having very large work like this
>> target a frozen branch and then also needing to pull it up to trunk. That
>> doesn't sound fun.
>>
>> If we resurrected the discussion about cutting alpha snapshots from
>> trunk, would that change people's perspectives on the weight of this
>> current decision? We'd probably also have to re-open pandora's box talking
>> about the solidity of our API's on trunk as well if we positioned those
>> alphas as being stable enough to start prototyping and/or building future
>> applications against.
>>
>> On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote:
>>
>> I am +1 on a 5.0 branch freeze.
>>
>> Kind Regards,
>> Brandon
>>
>> On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer  wrote:
>> >>
>> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
>> >
>> >
>> > I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and
>> allowing only CEP-15 and 21 + bug fixes there.
>> > Le ven. 24 mars 2023 à 13:55, Paulo Motta  a
>> écrit :
>> >>
>> >> >  I would like to propose a partial freeze of 5.0 in June.
>> >>
>> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I
>> agree with a branch freeze, but not with trunk freeze.
>> >>
>> >> I might work on small features after June and would be happy to delay
>> releasing these on 5.0+, but delaying merge to trunk until 5.0 is released
>> could be disruptive to contributors workflows and I would prefer to avoid
>> that if possible.
>> >>
>> >> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever 
>> wrote:
>> >>>
>> >>>
>>  I would like to propose a partial freeze of 5.0 in June.
>> 
>>  …
>> 
>>  This partial freeze will be valid for every new feature except
>> CEP-21 and CEP-15.
>> >>>
>> >>>
>> >>>
>> >>> +1
>> >>>
>> >>> Thanks for summarising the thread this way Benjamin. This addresses
>> my two main concerns: letting the branch/release date slip too much into
>> the unknown, squeezing GA QA efforts, while putting in place exceptional
>> waivers for CEP-21 and CEP-15.
>> >>>
>> >>> I hope that in the future we will be more willing to commit to the
>> release train model: less concerned about "what the next release contains";
>> more comfortable letting big features land where

Re: [EXTERNAL] [DISCUSS] Next release date

[Benjamin Lerer]

>
> I’m not sure what freezing early for “extra QA time” really buys us?


Tries, SAI, UCS, extended TTLs, Java 17, Dynamic Data Masking... all those
changes potentially introduce their set of issues/flakiness or other
problems. The freeze will allow us to find those early and facilitate the
integration of CEP 21 and 15 in my opinion.

Le ven. 24 mars 2023 à 16:23, Jeremiah D Jordan 
a écrit :

> Given the fundamental change to how cluster operations work coming from
> CEP-21, I’m not sure what freezing early for “extra QA time” really buys
> us?  I wouldn’t trust any multi-node QA done pre commit.
> What “stabilizing” do we expect to be doing during this time?  How much of
> it do we just have to do again after those things merge?  I for one do not
> like to have release branches cut months before their expected release.  It
> just adds extra merge forward and “where should this go”
> questions/overhead.  It could make sense to me to branch branch when CEP-21
> merges and only let in CEP-15 after that.  CEP-15 is mostly “net new stuff”
> and not “changes to existing stuff” from my understanding?  So no QA effort
> wasted if it is done before it merges.
>
> -Jeremiah
>
> On Mar 24, 2023, at 9:38 AM, Josh McKenzie  wrote:
>
> I would like to propose a partial freeze of 5.0 in June
>
> My .02:
> +1 to:
> * partial freeze on an agreed upon date w/agreed upon other things that
> can optionally go in after
> * setting a hard limit on when we ship from that frozen branch regardless
> of whether the features land or not
>
> -1 to:
> * ever feature freezing trunk again. :)
>
> I worry about the labor involved with having very large work like this
> target a frozen branch and then also needing to pull it up to trunk. That
> doesn't sound fun.
>
> If we resurrected the discussion about cutting alpha snapshots from trunk,
> would that change people's perspectives on the weight of this current
> decision? We'd probably also have to re-open pandora's box talking about
> the solidity of our API's on trunk as well if we positioned those alphas as
> being stable enough to start prototyping and/or building future
> applications against.
>
> On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote:
>
> I am +1 on a 5.0 branch freeze.
>
> Kind Regards,
> Brandon
>
> On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer  wrote:
> >>
> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
> >
> >
> > I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and
> allowing only CEP-15 and 21 + bug fixes there.
> > Le ven. 24 mars 2023 à 13:55, Paulo Motta  a
> écrit :
> >>
> >> >  I would like to propose a partial freeze of 5.0 in June.
> >>
> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I
> agree with a branch freeze, but not with trunk freeze.
> >>
> >> I might work on small features after June and would be happy to delay
> releasing these on 5.0+, but delaying merge to trunk until 5.0 is released
> could be disruptive to contributors workflows and I would prefer to avoid
> that if possible.
> >>
> >> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever  wrote:
> >>>
> >>>
>  I would like to propose a partial freeze of 5.0 in June.
> 
>  …
> 
>  This partial freeze will be valid for every new feature except CEP-21
> and CEP-15.
> >>>
> >>>
> >>>
> >>> +1
> >>>
> >>> Thanks for summarising the thread this way Benjamin. This addresses my
> two main concerns: letting the branch/release date slip too much into the
> unknown, squeezing GA QA efforts, while putting in place exceptional
> waivers for CEP-21 and CEP-15.
> >>>
> >>> I hope that in the future we will be more willing to commit to the
> release train model: less concerned about "what the next release contains";
> more comfortable letting big features land where they land. But this is
> opinion and discussion for another day… possibly looping back to the
> discussion on preview releases…
> >>>
> >>>
> >>> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21)
> landing in trunk?
> >>>
> >>>
>
>
>

Re: [EXTERNAL] [DISCUSS] Next release date

[Jeremiah D Jordan]

Given the fundamental change to how cluster operations work coming from CEP-21, 
I’m not sure what freezing early for “extra QA time” really buys us?  I 
wouldn’t trust any multi-node QA done pre commit.
What “stabilizing” do we expect to be doing during this time?  How much of it 
do we just have to do again after those things merge?  I for one do not like to 
have release branches cut months before their expected release.  It just adds 
extra merge forward and “where should this go” questions/overhead.  It could 
make sense to me to branch branch when CEP-21 merges and only let in CEP-15 
after that.  CEP-15 is mostly “net new stuff” and not “changes to existing 
stuff” from my understanding?  So no QA effort wasted if it is done before it 
merges.

-Jeremiah

> On Mar 24, 2023, at 9:38 AM, Josh McKenzie  wrote:
> 
>> I would like to propose a partial freeze of 5.0 in June
> My .02:
> +1 to:
> * partial freeze on an agreed upon date w/agreed upon other things that can 
> optionally go in after
> * setting a hard limit on when we ship from that frozen branch regardless of 
> whether the features land or not
> 
> -1 to:
> * ever feature freezing trunk again. :)
> 
> I worry about the labor involved with having very large work like this target 
> a frozen branch and then also needing to pull it up to trunk. That doesn't 
> sound fun.
> 
> If we resurrected the discussion about cutting alpha snapshots from trunk, 
> would that change people's perspectives on the weight of this current 
> decision? We'd probably also have to re-open pandora's box talking about the 
> solidity of our API's on trunk as well if we positioned those alphas as being 
> stable enough to start prototyping and/or building future applications 
> against.
> 
> On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote:
>> I am +1 on a 5.0 branch freeze.
>> 
>> Kind Regards,
>> Brandon
>> 
>> On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer > > wrote:
>> >>
>> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
>> >
>> >
>> > I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and 
>> > allowing only CEP-15 and 21 + bug fixes there.
>> > Le ven. 24 mars 2023 à 13:55, Paulo Motta > > > a écrit :
>> >>
>> >> >  I would like to propose a partial freeze of 5.0 in June.
>> >>
>> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I 
>> >> agree with a branch freeze, but not with trunk freeze.
>> >>
>> >> I might work on small features after June and would be happy to delay 
>> >> releasing these on 5.0+, but delaying merge to trunk until 5.0 is 
>> >> released could be disruptive to contributors workflows and I would prefer 
>> >> to avoid that if possible.
>> >>
>> >> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever > >> > wrote:
>> >>>
>> >>>
>>  I would like to propose a partial freeze of 5.0 in June.
>> 
>>  …
>> 
>>  This partial freeze will be valid for every new feature except CEP-21 
>>  and CEP-15.
>> >>>
>> >>>
>> >>>
>> >>> +1
>> >>>
>> >>> Thanks for summarising the thread this way Benjamin. This addresses my 
>> >>> two main concerns: letting the branch/release date slip too much into 
>> >>> the unknown, squeezing GA QA efforts, while putting in place exceptional 
>> >>> waivers for CEP-21 and CEP-15.
>> >>>
>> >>> I hope that in the future we will be more willing to commit to the 
>> >>> release train model: less concerned about "what the next release 
>> >>> contains"; more comfortable letting big features land where they land. 
>> >>> But this is opinion and discussion for another day… possibly looping 
>> >>> back to the discussion on preview releases…
>> >>>
>> >>>
>> >>> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21) landing 
>> >>> in trunk?
>> >>>
>> >>>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Josh McKenzie]

> I would like to propose a partial freeze of 5.0 in June
My .02:
+1 to:
* partial freeze on an agreed upon date w/agreed upon other things that can 
optionally go in after
* setting a hard limit on when we ship from that frozen branch regardless of 
whether the features land or not

-1 to:
* ever feature freezing trunk again. :)

I worry about the labor involved with having very large work like this target a 
frozen branch and then also needing to pull it up to trunk. That doesn't sound 
fun.

If we resurrected the discussion about cutting alpha snapshots from trunk, 
would that change people's perspectives on the weight of this current decision? 
We'd probably also have to re-open pandora's box talking about the solidity of 
our API's on trunk as well if we positioned those alphas as being stable enough 
to start prototyping and/or building future applications against.

On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote:
> I am +1 on a 5.0 branch freeze.
> 
> Kind Regards,
> Brandon
> 
> On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer  wrote:
> >>
> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
> >
> >
> > I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and 
> > allowing only CEP-15 and 21 + bug fixes there.
> > Le ven. 24 mars 2023 à 13:55, Paulo Motta  a 
> > écrit :
> >>
> >> >  I would like to propose a partial freeze of 5.0 in June.
> >>
> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I agree 
> >> with a branch freeze, but not with trunk freeze.
> >>
> >> I might work on small features after June and would be happy to delay 
> >> releasing these on 5.0+, but delaying merge to trunk until 5.0 is released 
> >> could be disruptive to contributors workflows and I would prefer to avoid 
> >> that if possible.
> >>
> >> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever  wrote:
> >>>
> >>>
>  I would like to propose a partial freeze of 5.0 in June.
> 
>  …
> 
>  This partial freeze will be valid for every new feature except CEP-21 
>  and CEP-15.
> >>>
> >>>
> >>>
> >>> +1
> >>>
> >>> Thanks for summarising the thread this way Benjamin. This addresses my 
> >>> two main concerns: letting the branch/release date slip too much into the 
> >>> unknown, squeezing GA QA efforts, while putting in place exceptional 
> >>> waivers for CEP-21 and CEP-15.
> >>>
> >>> I hope that in the future we will be more willing to commit to the 
> >>> release train model: less concerned about "what the next release 
> >>> contains"; more comfortable letting big features land where they land. 
> >>> But this is opinion and discussion for another day… possibly looping back 
> >>> to the discussion on preview releases…
> >>>
> >>>
> >>> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21) landing 
> >>> in trunk?
> >>>
> >>>
> 

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Brandon Williams]

I am +1 on a 5.0 branch freeze.

Kind Regards,
Brandon

On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer  wrote:
>>
>> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
>
>
> I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and 
> allowing only CEP-15 and 21 + bug fixes there.
> Le ven. 24 mars 2023 à 13:55, Paulo Motta  a écrit :
>>
>> >  I would like to propose a partial freeze of 5.0 in June.
>>
>> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I agree 
>> with a branch freeze, but not with trunk freeze.
>>
>> I might work on small features after June and would be happy to delay 
>> releasing these on 5.0+, but delaying merge to trunk until 5.0 is released 
>> could be disruptive to contributors workflows and I would prefer to avoid 
>> that if possible.
>>
>> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever  wrote:
>>>
>>>
 I would like to propose a partial freeze of 5.0 in June.

 …

 This partial freeze will be valid for every new feature except CEP-21 and 
 CEP-15.
>>>
>>>
>>>
>>> +1
>>>
>>> Thanks for summarising the thread this way Benjamin. This addresses my two 
>>> main concerns: letting the branch/release date slip too much into the 
>>> unknown, squeezing GA QA efforts, while putting in place exceptional 
>>> waivers for CEP-21 and CEP-15.
>>>
>>> I hope that in the future we will be more willing to commit to the release 
>>> train model: less concerned about "what the next release contains"; more 
>>> comfortable letting big features land where they land. But this is opinion 
>>> and discussion for another day… possibly looping back to the discussion on 
>>> preview releases…
>>>
>>>
>>> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21) landing in 
>>> trunk?
>>>
>>>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Benjamin Lerer]

>
> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?


I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and
allowing only CEP-15 and 21 + bug fixes there.
Le ven. 24 mars 2023 à 13:55, Paulo Motta  a
écrit :

> >  I would like to propose a partial freeze of 5.0 in June.
>
> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I agree
> with a branch freeze, but not with trunk freeze.
>
> I might work on small features after June and would be happy to delay
> releasing these on 5.0+, but delaying merge to trunk until 5.0 is released
> could be disruptive to contributors workflows and I would prefer to avoid
> that if possible.
>
> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever  wrote:
>
>>
>> I would like to propose a partial freeze of 5.0 in June.
>>>
>> …
>>>
>> This partial freeze will be valid for every new feature except CEP-21 and
>>> CEP-15.
>>>
>>
>>
>> +1
>>
>> Thanks for summarising the thread this way Benjamin. This addresses my
>> two main concerns: letting the branch/release date slip too much into the
>> unknown, squeezing GA QA efforts, while putting in place exceptional
>> waivers for CEP-21 and CEP-15.
>>
>> I hope that in the future we will be more willing to commit to the
>> release train model: less concerned about "what the next release contains";
>> more comfortable letting big features land where they land. But this is
>> opinion and discussion for another day… possibly looping back to the
>> discussion on preview releases…
>>
>>
>> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21) landing
>> in trunk?
>>
>>
>>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Paulo Motta]

>  I would like to propose a partial freeze of 5.0 in June.

Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I agree
with a branch freeze, but not with trunk freeze.

I might work on small features after June and would be happy to delay
releasing these on 5.0+, but delaying merge to trunk until 5.0 is released
could be disruptive to contributors workflows and I would prefer to avoid
that if possible.

On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever  wrote:

>
> I would like to propose a partial freeze of 5.0 in June.
>>
> …
>>
> This partial freeze will be valid for every new feature except CEP-21 and
>> CEP-15.
>>
>
>
> +1
>
> Thanks for summarising the thread this way Benjamin. This addresses my two
> main concerns: letting the branch/release date slip too much into the
> unknown, squeezing GA QA efforts, while putting in place exceptional
> waivers for CEP-21 and CEP-15.
>
> I hope that in the future we will be more willing to commit to the release
> train model: less concerned about "what the next release contains"; more
> comfortable letting big features land where they land. But this is opinion
> and discussion for another day… possibly looping back to the discussion on
> preview releases…
>
>
> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21) landing
> in trunk?
>
>
>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Mick Semb Wever]

> I would like to propose a partial freeze of 5.0 in June.
>
…
>
This partial freeze will be valid for every new feature except CEP-21 and
> CEP-15.
>


+1

Thanks for summarising the thread this way Benjamin. This addresses my two
main concerns: letting the branch/release date slip too much into the
unknown, squeezing GA QA efforts, while putting in place exceptional
waivers for CEP-21 and CEP-15.

I hope that in the future we will be more willing to commit to the release
train model: less concerned about "what the next release contains"; more
comfortable letting big features land where they land. But this is opinion
and discussion for another day… possibly looping back to the discussion on
preview releases…


Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21) landing in
trunk?

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Benjamin Lerer]

. I'm just 
>>>>> thinking
>>>>> from my personal experience: everything I've worked on, overseen, or
>>>>> followed closely on this codebase always has a few tricks up its sleeve
>>>>> along the way to having edge-cases stabilized.
>>>>>
>>>>> Much like on some other recent topics, I think there's a nuanced
>>>>> middle ground where we take things on a case-by-case basis. Some factors
>>>>> that have come up in this thread that resonated with me:
>>>>>
>>>>> For a given potential release date 'X':
>>>>> 1. How long has it been since the last release?
>>>>> 2. How long do we expect qualification to take from a "freeze" (i.e.
>>>>> no new improvement or features, branch) point?
>>>>> 3. What body of merged production ready work is available?
>>>>> 4. What body of new work do we have high confidence will be ready
>>>>> within Y time?
>>>>>
>>>>> I think it's worth defining a loose "minimum bound and upper bound" on
>>>>> release cycles we want to try and stick with barring extenuating
>>>>> circumstances. For instance: try not to release sooner than maybe 10 
>>>>> months
>>>>> out from a prior major, and try not to release later than 18 months out
>>>>> from a prior major. Make exceptions if truly exceptional things land, are
>>>>> about to land, or bugs are discovered around those boundaries.
>>>>>
>>>>> Applying the above framework to what we have in flight, our last
>>>>> release date, expectations on CI, etc - targeting an early fall freeze
>>>>> (pending CEP status) and mid to late fall or December release "feels 
>>>>> right"
>>>>> to me.
>>>>>
>>>>> With the exception, of course, that if something merges earlier, is
>>>>> stable, and we feel is valuable enough to cut a major based on that, we do
>>>>> it.
>>>>>
>>>>> ~Josh
>>>>>
>>>>> On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> We shouldn't release just for releases sake. Are there enough new
>>>>> features and are they working well enough (quality!).
>>>>>
>>>>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I
>>>>> would advocate to delay until this has sufficient quality to be in
>>>>> production.
>>>>>
>>>>> Just because something is released doesn't mean anyone is gonna use
>>>>> it. To add some operator perspective: Every time there is a new release we
>>>>> need to decide
>>>>> 1) are we supporting it
>>>>> 2) which other release can we deprecate
>>>>>
>>>>> and potentially migrate people - which is also a tough sell if there
>>>>> are no significant features and/or breaking changes.  So from my
>>>>> perspective less frequent releases are better - after all we haven't 
>>>>> gotten
>>>>> around to support 4.1 🙂
>>>>>
>>>>> The 5.0 release is also coupled with deprecating  3.11 which is what a
>>>>> significant amount of people are using - given 4.1 took longer I am not
>>>>> sure how many people are assuming that 5 will be delayed and haven't made
>>>>> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a
>>>>> bit more deliberate with releasing 5.0 and having a longer beta phase are
>>>>> all things we should consider.
>>>>>
>>>>> My 2cts,
>>>>> German
>>>>>
>>>>> *From:* Benedict 
>>>>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>>>>> *To:* dev@cassandra.apache.org 
>>>>> *Subject:* [EXTERNAL] Re: [DISCUSS] Next release date
>>>>>
>>>>>
>>>>> It doesn’t look like we agreed to a policy of annual branch dates,
>>>>> only annual releases and that we would schedule this for 4.1 based on 
>>>>> 4.0’s
>>>>> branch date. Given this was the reasoning proposed I can see why folk 
>>>>> would
>>>>> expect this would happen for the next release. I don’t think th

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Mike Adamson]

a prior major. Make exceptions if truly exceptional things land, are
>>>> about to land, or bugs are discovered around those boundaries.
>>>>
>>>> Applying the above framework to what we have in flight, our last
>>>> release date, expectations on CI, etc - targeting an early fall freeze
>>>> (pending CEP status) and mid to late fall or December release "feels right"
>>>> to me.
>>>>
>>>> With the exception, of course, that if something merges earlier, is
>>>> stable, and we feel is valuable enough to cut a major based on that, we do
>>>> it.
>>>>
>>>> ~Josh
>>>>
>>>> On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote:
>>>>
>>>> Hi,
>>>>
>>>> We shouldn't release just for releases sake. Are there enough new
>>>> features and are they working well enough (quality!).
>>>>
>>>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I
>>>> would advocate to delay until this has sufficient quality to be in
>>>> production.
>>>>
>>>> Just because something is released doesn't mean anyone is gonna use it.
>>>> To add some operator perspective: Every time there is a new release we need
>>>> to decide
>>>> 1) are we supporting it
>>>> 2) which other release can we deprecate
>>>>
>>>> and potentially migrate people - which is also a tough sell if there
>>>> are no significant features and/or breaking changes.  So from my
>>>> perspective less frequent releases are better - after all we haven't gotten
>>>> around to support 4.1 🙂
>>>>
>>>> The 5.0 release is also coupled with deprecating  3.11 which is what a
>>>> significant amount of people are using - given 4.1 took longer I am not
>>>> sure how many people are assuming that 5 will be delayed and haven't made
>>>> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a
>>>> bit more deliberate with releasing 5.0 and having a longer beta phase are
>>>> all things we should consider.
>>>>
>>>> My 2cts,
>>>> German
>>>>
>>>> *From:* Benedict 
>>>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>>>> *To:* dev@cassandra.apache.org 
>>>> *Subject:* [EXTERNAL] Re: [DISCUSS] Next release date
>>>>
>>>>
>>>> It doesn’t look like we agreed to a policy of annual branch dates, only
>>>> annual releases and that we would schedule this for 4.1 based on 4.0’s
>>>> branch date. Given this was the reasoning proposed I can see why folk would
>>>> expect this would happen for the next release. I don’t think there was a
>>>> strong enough commitment here to be bound by, it if we think different
>>>> maths would work better.
>>>>
>>>> I recall the goal for an annual cadence was to ensure we don’t have
>>>> lengthy periods between releases like 3.x to 4.0, and to try to reduce the
>>>> pressure certain contributors might feel to hit a specific release with a
>>>> given feature.
>>>>
>>>> I think it’s better to revisit these underlying reasons and check how
>>>> they apply than to pick a mechanism and stick to it too closely.
>>>>
>>>> The last release was quite recent, so we aren’t at risk of slow
>>>> releases here. Similarly, there are some features that the *project* would
>>>> probably benefit from landing prior to release, if this doesn’t push
>>>> release back too far.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 1 Mar 2023, at 13:38, Mick Semb Wever  wrote:
>>>>
>>>> 
>>>>
>>>> My thoughts don't touch on CEPs inflight.
>>>>
>>>>
>>>>
>>>>
>>>> For the sake of broadening the discussion, additional questions I think
>>>> worthwhile to raise are…
>>>>
>>>> 1. What third parties, or other initiatives, are invested and/or
>>>> working against the May deadline? and what are their views on changing it?
>>>>   1a. If we push branching back to September, how confident are we
>>>> that we'll get to GA before the December Summit?
>>>> 2. What CEPs look like not landing by May that we consider a must-have
>>&

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Ekaterina Dimitrova]

ll be ready
>>>> within Y time?
>>>>
>>>> I think it's worth defining a loose "minimum bound and upper bound" on
>>>> release cycles we want to try and stick with barring extenuating
>>>> circumstances. For instance: try not to release sooner than maybe 10 months
>>>> out from a prior major, and try not to release later than 18 months out
>>>> from a prior major. Make exceptions if truly exceptional things land, are
>>>> about to land, or bugs are discovered around those boundaries.
>>>>
>>>> Applying the above framework to what we have in flight, our last
>>>> release date, expectations on CI, etc - targeting an early fall freeze
>>>> (pending CEP status) and mid to late fall or December release "feels right"
>>>> to me.
>>>>
>>>> With the exception, of course, that if something merges earlier, is
>>>> stable, and we feel is valuable enough to cut a major based on that, we do
>>>> it.
>>>>
>>>> ~Josh
>>>>
>>>> On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote:
>>>>
>>>> Hi,
>>>>
>>>> We shouldn't release just for releases sake. Are there enough new
>>>> features and are they working well enough (quality!).
>>>>
>>>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I
>>>> would advocate to delay until this has sufficient quality to be in
>>>> production.
>>>>
>>>> Just because something is released doesn't mean anyone is gonna use it.
>>>> To add some operator perspective: Every time there is a new release we need
>>>> to decide
>>>> 1) are we supporting it
>>>> 2) which other release can we deprecate
>>>>
>>>> and potentially migrate people - which is also a tough sell if there
>>>> are no significant features and/or breaking changes.  So from my
>>>> perspective less frequent releases are better - after all we haven't gotten
>>>> around to support 4.1 🙂
>>>>
>>>> The 5.0 release is also coupled with deprecating  3.11 which is what a
>>>> significant amount of people are using - given 4.1 took longer I am not
>>>> sure how many people are assuming that 5 will be delayed and haven't made
>>>> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a
>>>> bit more deliberate with releasing 5.0 and having a longer beta phase are
>>>> all things we should consider.
>>>>
>>>> My 2cts,
>>>> German
>>>>
>>>> *From:* Benedict 
>>>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>>>> *To:* dev@cassandra.apache.org 
>>>> *Subject:* [EXTERNAL] Re: [DISCUSS] Next release date
>>>>
>>>>
>>>> It doesn’t look like we agreed to a policy of annual branch dates, only
>>>> annual releases and that we would schedule this for 4.1 based on 4.0’s
>>>> branch date. Given this was the reasoning proposed I can see why folk would
>>>> expect this would happen for the next release. I don’t think there was a
>>>> strong enough commitment here to be bound by, it if we think different
>>>> maths would work better.
>>>>
>>>> I recall the goal for an annual cadence was to ensure we don’t have
>>>> lengthy periods between releases like 3.x to 4.0, and to try to reduce the
>>>> pressure certain contributors might feel to hit a specific release with a
>>>> given feature.
>>>>
>>>> I think it’s better to revisit these underlying reasons and check how
>>>> they apply than to pick a mechanism and stick to it too closely.
>>>>
>>>> The last release was quite recent, so we aren’t at risk of slow
>>>> releases here. Similarly, there are some features that the *project* would
>>>> probably benefit from landing prior to release, if this doesn’t push
>>>> release back too far.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 1 Mar 2023, at 13:38, Mick Semb Wever  wrote:
>>>>
>>>> 
>>>>
>>>> My thoughts don't touch on CEPs inflight.
>>>>
>>>>
>>>>
>>>>
>>>> For the sake of broadening the discussion, additional questions I think
>>>> worthwhile to raise are…
>>>>
>>>> 1. What third parties, or other initiatives, are invested and/or
>>>> working against the May deadline? and what are their views on changing it?
>>>>   1a. If we push branching back to September, how confident are we
>>>> that we'll get to GA before the December Summit?
>>>> 2. What CEPs look like not landing by May that we consider a must-have
>>>> this year?
>>>>   2a. Is it just tail-end commits in those CEPs that won't make it? Can
>>>> these land (with or without a waiver) during the alpha phase?
>>>>   2b. If the final components to specified CEPs are not
>>>> approved/appropriate to land during alpha, would it be better if the
>>>> project commits to a one-off half-year release later in the year?
>>>>
>>>>
>>>>
>
> --
> [image: DataStax Logo Square] <https://www.datastax.com/> *Mike Adamson*
> Engineering
>
> +1 650 389 6000 <16503896000> | datastax.com <https://www.datastax.com/>
> Find DataStax Online: [image: LinkedIn Logo]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=>
>[image: Facebook Logo]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=>
>[image: Twitter Logo] <https://twitter.com/DataStax>   [image: RSS
> Feed] <https://www.datastax.com/blog/rss.xml>   [image: Github Logo]
> <https://github.com/datastax>
>
>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Berenguer Blasi]

 targeting
an early fall freeze (pending CEP status) and mid to late
fall or December release "feels right" to me.

With the exception, of course, that if something merges
earlier, is stable, and we feel is valuable enough to cut
a major based on that, we do it.

~Josh

On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev
wrote:

Hi,

We shouldn't release just for releases sake. Are there
enough new features and are they working well enough
(quality!).

The big feature from our perspective for 5.0 is ACCORD
(CEP-15) and I would advocate to delay until this has
sufficient quality to be in production.

Just because something is released doesn't mean anyone is
gonna use it. To add some operator perspective: Every
time there is a new release we need to decide
1) are we supporting it
2) which other release can we deprecate

and potentially migrate people - which is also a tough
sell if there are no significant features and/or breaking
changes.  So from my perspective less frequent releases
are better - after all we haven't gotten around to
support 4.1 🙂

The 5.0 release is also coupled with deprecating  3.11
which is what a significant amount of people are using -
given 4.1 took longer I am not sure how many people are
assuming that 5 will be delayed and haven't made plans
(OpenJDK support for 8 is longer than Java 17 🙂) . So
being a bit more deliberate with releasing 5.0 and having
a longer beta phase are all things we should consider.

My 2cts,
German

*From:* Benedict 
*Sent:* Wednesday, March 1, 2023 5:59 AM
*To:* dev@cassandra.apache.org 
*Subject:* [EXTERNAL] Re: [DISCUSS] Next release date


It doesn’t look like we agreed to a policy of annual
branch dates, only annual releases and that we would
schedule this for 4.1 based on 4.0’s branch date. Given
this was the reasoning proposed I can see why folk would
expect this would happen for the next release. I don’t
think there was a strong enough commitment here to be
bound by, it if we think different maths would work better.

I recall the goal for an annual cadence was to ensure we
don’t have lengthy periods between releases like 3.x to
4.0, and to try to reduce the pressure certain
contributors might feel to hit a specific release with a
given feature.

I think it’s better to revisit these underlying reasons
and check how they apply than to pick a mechanism and
stick to it too closely.

The last release was quite recent, so we aren’t at risk
of slow releases here. Similarly, there are some features
that the *project* would probably benefit from landing
prior to release, if this doesn’t push release back too far.






On 1 Mar 2023, at 13:38, Mick Semb Wever
 wrote:


My thoughts don't touch on CEPs inflight.




For the sake of broadening the discussion, additional
questions I think worthwhile to raise are…

1. What third parties, or other initiatives, are
invested and/or working against the May deadline? and
what are their views on changing it?
1a. If we push branching back to September, how
confident are we that we'll get to GA before the
December Summit?
2. What CEPs look like not landing by Maythat we
consider a must-have this year?
2a. Is it just tail-end commits in those CEPs that won't
make it? Can these land (withor without a waiver) during
the alpha phase?
  2b. If the final components to specified CEPs are not
approved/appropriate to land during alpha, would it be
better if the project commits to a one-off half-year
release later in the year?




--
DataStax Logo Square <https://www.datastax.com/>  *Mike Adamson*
Engineering

+1 650 389 6000 |datastax.com 
<https://www.datastax.com/>


Find DataStax Online: 	LinkedIn Logo 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=> 
Facebook Logo 
<https://urldefense.proofpoint.com/v2

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Mike Adamson]

is valuable enough to cut a major based on that, we do
>>> it.
>>>
>>> ~Josh
>>>
>>> On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote:
>>>
>>> Hi,
>>>
>>> We shouldn't release just for releases sake. Are there enough new
>>> features and are they working well enough (quality!).
>>>
>>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I
>>> would advocate to delay until this has sufficient quality to be in
>>> production.
>>>
>>> Just because something is released doesn't mean anyone is gonna use it.
>>> To add some operator perspective: Every time there is a new release we need
>>> to decide
>>> 1) are we supporting it
>>> 2) which other release can we deprecate
>>>
>>> and potentially migrate people - which is also a tough sell if there are
>>> no significant features and/or breaking changes.  So from my perspective
>>> less frequent releases are better - after all we haven't gotten around to
>>> support 4.1 🙂
>>>
>>> The 5.0 release is also coupled with deprecating  3.11 which is what a
>>> significant amount of people are using - given 4.1 took longer I am not
>>> sure how many people are assuming that 5 will be delayed and haven't made
>>> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a
>>> bit more deliberate with releasing 5.0 and having a longer beta phase are
>>> all things we should consider.
>>>
>>> My 2cts,
>>> German
>>>
>>> *From:* Benedict 
>>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>>> *To:* dev@cassandra.apache.org 
>>> *Subject:* [EXTERNAL] Re: [DISCUSS] Next release date
>>>
>>>
>>> It doesn’t look like we agreed to a policy of annual branch dates, only
>>> annual releases and that we would schedule this for 4.1 based on 4.0’s
>>> branch date. Given this was the reasoning proposed I can see why folk would
>>> expect this would happen for the next release. I don’t think there was a
>>> strong enough commitment here to be bound by, it if we think different
>>> maths would work better.
>>>
>>> I recall the goal for an annual cadence was to ensure we don’t have
>>> lengthy periods between releases like 3.x to 4.0, and to try to reduce the
>>> pressure certain contributors might feel to hit a specific release with a
>>> given feature.
>>>
>>> I think it’s better to revisit these underlying reasons and check how
>>> they apply than to pick a mechanism and stick to it too closely.
>>>
>>> The last release was quite recent, so we aren’t at risk of slow releases
>>> here. Similarly, there are some features that the *project* would probably
>>> benefit from landing prior to release, if this doesn’t push release back
>>> too far.
>>>
>>>
>>>
>>>
>>>
>>> On 1 Mar 2023, at 13:38, Mick Semb Wever  wrote:
>>>
>>> 
>>>
>>> My thoughts don't touch on CEPs inflight.
>>>
>>>
>>>
>>>
>>> For the sake of broadening the discussion, additional questions I think
>>> worthwhile to raise are…
>>>
>>> 1. What third parties, or other initiatives, are invested and/or
>>> working against the May deadline? and what are their views on changing it?
>>>   1a. If we push branching back to September, how confident are we that
>>> we'll get to GA before the December Summit?
>>> 2. What CEPs look like not landing by May that we consider a must-have
>>> this year?
>>>   2a. Is it just tail-end commits in those CEPs that won't make it? Can
>>> these land (with or without a waiver) during the alpha phase?
>>>   2b. If the final components to specified CEPs are not
>>> approved/appropriate to land during alpha, would it be better if the
>>> project commits to a one-off half-year release later in the year?
>>>
>>>
>>>

-- 
[image: DataStax Logo Square] <https://www.datastax.com/> *Mike Adamson*
Engineering

+1 650 389 6000 <16503896000> | datastax.com <https://www.datastax.com/>
Find DataStax Online: [image: LinkedIn Logo]
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=>
   [image: Facebook Logo]
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=>
   [image: Twitter Logo] <https://twitter.com/DataStax>   [image: RSS Feed]
<https://www.datastax.com/blog/rss.xml>   [image: Github Logo]
<https://github.com/datastax>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Andrés de la Peña]

>
> Should we clarify that part first by getting an idea of the status of the
> different CEPs and other big pieces of work?


CEP-20 (dynamic data masking) should hopefully be ready by the end of this
month.

It's composed by seven small tickets. Five of those tickets are ready, and
two are under review. All together it will be ~6K LOC, involving around 100
files.

On Thu, 9 Mar 2023 at 21:17, Mick Semb Wever  wrote:

> > > > One place we've been weak historically is in distinguishing between
> tickets we consider "nice to have" and things that are "blockers". We don't
> have any metadata that currently distinguishes those two, so determining
> what our burndown leading up to 5.0 looks like is a lot more data massaging
> and hand-waving than I'd prefer right now.
> > >
> > > We distinguish "blockers" with `Priority=Urgent` or
> `Severity=Critical`, or by linking the ticket as blocking to a specific
> ticket that spells it out. We do have the metadata, but yes it requires
> some work…
> >
> > For everything not urgent or a blocker, does it matter whether something
> has a fixver of where we think it's going to land or where we'd like to see
> it land? At the end of the day, neither of those scenarios will actually
> shift a release date if we're proactively putting "blocker / urgent" status
> on new features, improvements, and bugs we think are significant enough to
> delay a release right?
>
>
> Ooops, actually we were using the -beta, and -rc fixVersion
> placeholders to denote the blockers once "the bridge was crossed"
> (while Urgent and Critical is used more broadly, e.g. patch releases).
> If we use this approach, then we could add a 5.0-alpha placeholder
> that indicates a consensus on tickets blocking the branching (if we
> agree alpha1 should be cut at the same time we branch…). IMHO such
> tickets should also still be marked as Urgent, but I suggest we use
> Urgent/Critical as an initial state, and the fixVersion placeholders
> where we have consensus or it is according to our release criteria
> :shrug:
>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Mick Semb Wever]

> > > One place we've been weak historically is in distinguishing between 
> > > tickets we consider "nice to have" and things that are "blockers". We 
> > > don't have any metadata that currently distinguishes those two, so 
> > > determining what our burndown leading up to 5.0 looks like is a lot more 
> > > data massaging and hand-waving than I'd prefer right now.
> >
> > We distinguish "blockers" with `Priority=Urgent` or `Severity=Critical`, or 
> > by linking the ticket as blocking to a specific ticket that spells it out. 
> > We do have the metadata, but yes it requires some work…
>
> For everything not urgent or a blocker, does it matter whether something has 
> a fixver of where we think it's going to land or where we'd like to see it 
> land? At the end of the day, neither of those scenarios will actually shift a 
> release date if we're proactively putting "blocker / urgent" status on new 
> features, improvements, and bugs we think are significant enough to delay a 
> release right?


Ooops, actually we were using the -beta, and -rc fixVersion
placeholders to denote the blockers once "the bridge was crossed"
(while Urgent and Critical is used more broadly, e.g. patch releases).
If we use this approach, then we could add a 5.0-alpha placeholder
that indicates a consensus on tickets blocking the branching (if we
agree alpha1 should be cut at the same time we branch…). IMHO such
tickets should also still be marked as Urgent, but I suggest we use
Urgent/Critical as an initial state, and the fixVersion placeholders
where we have consensus or it is according to our release criteria
:shrug:

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Josh McKenzie]

> We do have the metadata, but yes it requires some work…
My wording was poor; we have the *potential* to have this metadata, but to my 
knowledge we don't have a muscle of consistently setting this, or any kind of 
heuristic to determine when something should block a release or not. At least 
on 4.0 and 4.1, it seemed this was a bridge we crossed informally in the run up 
to a date trying to figure out what to include or discard.

> The project previously made an agreement to one release a year,
I don't recall the details (and searching our... rather active threads is an 
undertaking) - our site has a blog post here: 
https://cassandra.apache.org/_/blog/Apache-Cassandra-Changelog-7-May-2021.html, 
that states: "The community has agreed to one release every year, plus periodic 
trunk snapshots". While it reads like "one a calendar year" to me, at the end 
of the day what's important to me is we do right by our users. So whether we 
interpret that as every 12 months, once per calendar year, once every July with 
a freeze in May train style, all fine by me actually. I more or less stand by 
"just not 'release monthly' and not 'release once every three years'. :) Got 
any clarity there?

> I (and others) wish to do the exercise of running through our 5.x list and 
> pushing out everything we can see with no commitment or activity (and also 
> closing out old and now irrelevant/inapplicable tickets) (and this will be 
> done via a proposed filter). But a question here is the fixVersion can infer 
> where a ticket can be applied (appropriateness) or where we foresee it 
> landing (roadmap). 
I'm +1 to this. If people want something to be different they can just toggle 
it back and bring it to the ML or slack.

For everything not urgent or a blocker, does it matter whether something has a 
fixver of where we think it's going to land or where we'd like to see it land? 
At the end of the day, neither of those scenarios will actually shift a release 
date if we're proactively putting "blocker / urgent" status on new features, 
improvements, and bugs we think are significant enough to delay a release right?

On Thu, Mar 9, 2023, at 3:17 PM, Mick Semb Wever wrote:
>> One place we've been weak historically is in distinguishing between tickets 
>> we consider "nice to have" and things that are "blockers". We don't have any 
>> metadata that currently distinguishes those two, so determining what our 
>> burndown leading up to 5.0 looks like is a lot more data massaging and 
>> hand-waving than I'd prefer right now.
> 
> 
> We distinguish "blockers" with `Priority=Urgent` or `Severity=Critical`, or 
> by linking the ticket as blocking to a specific ticket that spells it out. We 
> do have the metadata, but yes it requires some work…
> 
> The project previously made an agreement to one release a year, akin to a 
> release train model, which helps justify why fixVersion 5.x has just fallen 
> to be "next". (And then there is no "burn-down" in such a model.) 
> 
> Our release criteria, especially post-branch, demonstrates that we do 
> introduce and rely on "blockers". If we agree that certain exceptional CEPs 
> are "blockers", a la warrant delaying the release date, using this approach 
> seems to fit in appropriately.
> 
> When I (just) folded fixVersion 4.2 into 5.0 (and 4.x into 5.x), I also 
> created 5.1.x and 6.x.  I (and others) wish to do the exercise of running 
> through our 5.x list and pushing out everything we can see with no commitment 
> or activity (and also closing out old and now irrelevant/inapplicable 
> tickets) (and this will be done via a proposed filter). But a question here 
> is the fixVersion can infer where a ticket can be applied (appropriateness) 
> or where we foresee it landing (roadmap). For example we mark bugs with the 
> fixVersions ideally they should be applied to, regardless of whether anyone 
> comes to address them or not. 
> 
> 
> 

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Mick Semb Wever]

>
> One place we've been weak historically is in distinguishing between
> tickets we consider "nice to have" and things that are "blockers". We don't
> have any metadata that currently distinguishes those two, so determining
> what our burndown leading up to 5.0 looks like is a lot more data massaging
> and hand-waving than I'd prefer right now.
>


We distinguish "blockers" with `Priority=Urgent` or `Severity=Critical`, or
by linking the ticket as blocking to a specific ticket that spells it out.
We do have the metadata, but yes it requires some work…

The project previously made an agreement to one release a year, akin to a
release train model, which helps justify why fixVersion 5.x has just fallen
to be "next". (And then there is no "burn-down" in such a model.)

Our release criteria, especially post-branch, demonstrates that we do
introduce and rely on "blockers". If we agree that certain exceptional CEPs
are "blockers", a la warrant delaying the release date, using this approach
seems to fit in appropriately.

When I (just) folded fixVersion 4.2 into 5.0 (and 4.x into 5.x), I also
created 5.1.x and 6.x.  I (and others) wish to do the exercise of running
through our 5.x list and pushing out everything we can see with no
commitment or activity (and also closing out old and now
irrelevant/inapplicable tickets) (and this will be done via a proposed
filter). But a question here is the fixVersion can infer where a ticket can
be applied (appropriateness) or where we foresee it landing (roadmap). For
example we mark bugs with the fixVersions ideally they should be applied
to, regardless of whether anyone comes to address them or not.

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Ekaterina Dimitrova]

There is also this roadmap page but we haven’t updated it lately. It
contains still 4.1 updates from last year.

https://cwiki.apache.org/confluence/display/CASSANDRA/Roadmap

On Thu, 9 Mar 2023 at 13:51, Josh McKenzie  wrote:

> Added an "Epics" quick filter; could help visualize what our high priority
> features are for given releases:
>
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2649
>
> Our cumulative flow diagram of 5.0 related tickets is pretty large.
> Probably not a great indicator for the body of what we expect to land in
> the release:
>
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&projectKey=CASSANDRA&view=reporting&chart=cumulativeFlowDiagram&swimlane=1212&swimlane=1412&swimlane=1413&column=2116&column=2117&column=2118&column=2130&column=2133&column=2124&column=2127&from=2021-12-20&to=2023-03-09
>
> One place we've been weak historically is in distinguishing between
> tickets we consider "nice to have" and things that are "blockers". We don't
> have any metadata that currently distinguishes those two, so determining
> what our burndown leading up to 5.0 looks like is a lot more data massaging
> and hand-waving than I'd prefer right now.
>
> I've been deep on some other issues for awhile but hope to get more
> involved in this space + ci within the next month or so.
>
> On Thu, Mar 9, 2023, at 9:15 AM, Mick Semb Wever wrote:
>
> I've also found some useful Cassandra's JIRA dashboards for previous
> releases to track progress and scope, but we don't have anything
> similar for the next release. Should we create it?
> Cassandra 4.0GAScope
> Cassandra 4.1 GA scope
>
>
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484
>
>
>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Josh McKenzie]

Added an "Epics" quick filter; could help visualize what our high priority 
features are for given releases:

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2649

Our cumulative flow diagram of 5.0 related tickets is pretty large. Probably 
not a great indicator for the body of what we expect to land in the release:

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&projectKey=CASSANDRA&view=reporting&chart=cumulativeFlowDiagram&swimlane=1212&swimlane=1412&swimlane=1413&column=2116&column=2117&column=2118&column=2130&column=2133&column=2124&column=2127&from=2021-12-20&to=2023-03-09

One place we've been weak historically is in distinguishing between tickets we 
consider "nice to have" and things that are "blockers". We don't have any 
metadata that currently distinguishes those two, so determining what our 
burndown leading up to 5.0 looks like is a lot more data massaging and 
hand-waving than I'd prefer right now.

I've been deep on some other issues for awhile but hope to get more involved in 
this space + ci within the next month or so.

On Thu, Mar 9, 2023, at 9:15 AM, Mick Semb Wever wrote:
>> I've also found some useful Cassandra's JIRA dashboards for previous
>> releases to track progress and scope, but we don't have anything
>> similar for the next release. Should we create it?
>> Cassandra 4.0GAScope
>> Cassandra 4.1 GA scope
> 
> 
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484  
> 

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Mick Semb Wever]

>
> I've also found some useful Cassandra's JIRA dashboards for previous
> releases to track progress and scope, but we don't have anything
> similar for the next release. Should we create it?
> Cassandra 4.0GAScope
> Cassandra 4.1 GA scope
>


https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Maxim Muzafarov]

 or bugs are discovered around those boundaries.
>>>
>>> Applying the above framework to what we have in flight, our last release 
>>> date, expectations on CI, etc - targeting an early fall freeze (pending CEP 
>>> status) and mid to late fall or December release "feels right" to me.
>>>
>>> With the exception, of course, that if something merges earlier, is stable, 
>>> and we feel is valuable enough to cut a major based on that, we do it.
>>>
>>> ~Josh
>>>
>>> On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote:
>>>
>>> Hi,
>>>
>>> We shouldn't release just for releases sake. Are there enough new features 
>>> and are they working well enough (quality!).
>>>
>>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I would 
>>> advocate to delay until this has sufficient quality to be in production.
>>>
>>> Just because something is released doesn't mean anyone is gonna use it. To 
>>> add some operator perspective: Every time there is a new release we need to 
>>> decide
>>> 1) are we supporting it
>>> 2) which other release can we deprecate
>>>
>>> and potentially migrate people - which is also a tough sell if there are no 
>>> significant features and/or breaking changes.  So from my perspective less 
>>> frequent releases are better - after all we haven't gotten around to 
>>> support 4.1 🙂
>>>
>>> The 5.0 release is also coupled with deprecating  3.11 which is what a 
>>> significant amount of people are using - given 4.1 took longer I am not 
>>> sure how many people are assuming that 5 will be delayed and haven't made 
>>> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit 
>>> more deliberate with releasing 5.0 and having a longer beta phase are all 
>>> things we should consider.
>>>
>>> My 2cts,
>>> German
>>>
>>> From: Benedict 
>>> Sent: Wednesday, March 1, 2023 5:59 AM
>>> To: dev@cassandra.apache.org 
>>> Subject: [EXTERNAL] Re: [DISCUSS] Next release date
>>>
>>>
>>> It doesn’t look like we agreed to a policy of annual branch dates, only 
>>> annual releases and that we would schedule this for 4.1 based on 4.0’s 
>>> branch date. Given this was the reasoning proposed I can see why folk would 
>>> expect this would happen for the next release. I don’t think there was a 
>>> strong enough commitment here to be bound by, it if we think different 
>>> maths would work better.
>>>
>>> I recall the goal for an annual cadence was to ensure we don’t have lengthy 
>>> periods between releases like 3.x to 4.0, and to try to reduce the pressure 
>>> certain contributors might feel to hit a specific release with a given 
>>> feature.
>>>
>>> I think it’s better to revisit these underlying reasons and check how they 
>>> apply than to pick a mechanism and stick to it too closely.
>>>
>>> The last release was quite recent, so we aren’t at risk of slow releases 
>>> here. Similarly, there are some features that the *project* would probably 
>>> benefit from landing prior to release, if this doesn’t push release back 
>>> too far.
>>>
>>>
>>>
>>>
>>>
>>> On 1 Mar 2023, at 13:38, Mick Semb Wever  wrote:
>>>
>>> 
>>>
>>> My thoughts don't touch on CEPs inflight.
>>>
>>>
>>>
>>>
>>> For the sake of broadening the discussion, additional questions I think 
>>> worthwhile to raise are…
>>>
>>> 1. What third parties, or other initiatives, are invested and/or working 
>>> against the May deadline? and what are their views on changing it?
>>>   1a. If we push branching back to September, how confident are we that 
>>> we'll get to GA before the December Summit?
>>> 2. What CEPs look like not landing by May that we consider a must-have this 
>>> year?
>>>   2a. Is it just tail-end commits in those CEPs that won't make it? Can 
>>> these land (with or without a waiver) during the alpha phase?
>>>   2b. If the final components to specified CEPs are not 
>>> approved/appropriate to land during alpha, would it be better if the 
>>> project commits to a one-off half-year release later in the year?
>>>
>>>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Branimir Lambov]

ere is a new release we need
>> to decide
>> 1) are we supporting it
>> 2) which other release can we deprecate
>>
>> and potentially migrate people - which is also a tough sell if there are
>> no significant features and/or breaking changes.  So from my perspective
>> less frequent releases are better - after all we haven't gotten around to
>> support 4.1 🙂
>>
>> The 5.0 release is also coupled with deprecating  3.11 which is what a
>> significant amount of people are using - given 4.1 took longer I am not
>> sure how many people are assuming that 5 will be delayed and haven't made
>> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit
>> more deliberate with releasing 5.0 and having a longer beta phase are all
>> things we should consider.
>>
>> My 2cts,
>> German
>>
>> *From:* Benedict 
>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>> *To:* dev@cassandra.apache.org 
>> *Subject:* [EXTERNAL] Re: [DISCUSS] Next release date
>>
>>
>> It doesn’t look like we agreed to a policy of annual branch dates, only
>> annual releases and that we would schedule this for 4.1 based on 4.0’s
>> branch date. Given this was the reasoning proposed I can see why folk would
>> expect this would happen for the next release. I don’t think there was a
>> strong enough commitment here to be bound by, it if we think different
>> maths would work better.
>>
>> I recall the goal for an annual cadence was to ensure we don’t have
>> lengthy periods between releases like 3.x to 4.0, and to try to reduce the
>> pressure certain contributors might feel to hit a specific release with a
>> given feature.
>>
>> I think it’s better to revisit these underlying reasons and check how
>> they apply than to pick a mechanism and stick to it too closely.
>>
>> The last release was quite recent, so we aren’t at risk of slow releases
>> here. Similarly, there are some features that the *project* would probably
>> benefit from landing prior to release, if this doesn’t push release back
>> too far.
>>
>>
>>
>>
>>
>> On 1 Mar 2023, at 13:38, Mick Semb Wever  wrote:
>>
>> 
>>
>> My thoughts don't touch on CEPs inflight.
>>
>>
>>
>>
>> For the sake of broadening the discussion, additional questions I think
>> worthwhile to raise are…
>>
>> 1. What third parties, or other initiatives, are invested and/or working
>> against the May deadline? and what are their views on changing it?
>>   1a. If we push branching back to September, how confident are we that
>> we'll get to GA before the December Summit?
>> 2. What CEPs look like not landing by May that we consider a must-have
>> this year?
>>   2a. Is it just tail-end commits in those CEPs that won't make it? Can
>> these land (with or without a waiver) during the alpha phase?
>>   2b. If the final components to specified CEPs are not
>> approved/appropriate to land during alpha, would it be better if the
>> project commits to a one-off half-year release later in the year?
>>
>>
>>

Re: [EXTERNAL] [DISCUSS] Next release date

[Mick Semb Wever]

On Tue, 7 Mar 2023 at 11:20, Sam Tunnicliffe  wrote:

> Currently, we anticipate CEP-21 being in a mergeable state around late
> July/August.
>


For me this is a more important reason to delay the branch date than
CEP-15, it being such a foundational change. Also, this is the first
feedback we've had that any CEP won't land by May.

Thank you Sam (and German) for the directness in your posts.

My concern remaining is the unknown branch to GA time, and the real risk of
not seeing a GA release (with highly anticipated features) landing this
year. I hope that delaying the branch date is accompanied with broad
commitments to fixing flakies, improving QA/CI, everything etc etc, so our
hope of a 2 month GA journey and a more stable trunk is realised.

Re: [EXTERNAL] [DISCUSS] Next release date

[Sam Tunnicliffe]

is ACCORD (CEP-15) and I would 
>>> advocate to delay until this has sufficient quality to be in production. 
>>> 
>>> Just because something is released doesn't mean anyone is gonna use it. To 
>>> add some operator perspective: Every time there is a new release we need to 
>>> decide 
>>> 1) are we supporting it 
>>> 2) which other release can we deprecate 
>>> 
>>> and potentially migrate people - which is also a tough sell if there are no 
>>> significant features and/or breaking changes.  So from my perspective less 
>>> frequent releases are better - after all we haven't gotten around to 
>>> support 4.1 🙂
>>> 
>>> The 5.0 release is also coupled with deprecating  3.11 which is what a 
>>> significant amount of people are using - given 4.1 took longer I am not 
>>> sure how many people are assuming that 5 will be delayed and haven't made 
>>> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit 
>>> more deliberate with releasing 5.0 and having a longer beta phase are all 
>>> things we should consider.
>>> 
>>> My 2cts,
>>> German
>>> 
>>> From: Benedict mailto:bened...@apache.org>>
>>> Sent: Wednesday, March 1, 2023 5:59 AM
>>> To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org> 
>>> mailto:dev@cassandra.apache.org>>
>>> Subject: [EXTERNAL] Re: [DISCUSS] Next release date
>>>  
>>> 
>>> It doesn’t look like we agreed to a policy of annual branch dates, only 
>>> annual releases and that we would schedule this for 4.1 based on 4.0’s 
>>> branch date. Given this was the reasoning proposed I can see why folk would 
>>> expect this would happen for the next release. I don’t think there was a 
>>> strong enough commitment here to be bound by, it if we think different 
>>> maths would work better.
>>> 
>>> I recall the goal for an annual cadence was to ensure we don’t have lengthy 
>>> periods between releases like 3.x to 4.0, and to try to reduce the pressure 
>>> certain contributors might feel to hit a specific release with a given 
>>> feature.
>>> 
>>> I think it’s better to revisit these underlying reasons and check how they 
>>> apply than to pick a mechanism and stick to it too closely. 
>>> 
>>> The last release was quite recent, so we aren’t at risk of slow releases 
>>> here. Similarly, there are some features that the *project* would probably 
>>> benefit from landing prior to release, if this doesn’t push release back 
>>> too far.
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 1 Mar 2023, at 13:38, Mick Semb Wever >>> <mailto:m...@apache.org>> wrote:
>>>> 
>>>> My thoughts don't touch on CEPs inflight. 
>>>> 
>>>> 
>>>> 
>>>> For the sake of broadening the discussion, additional questions I think 
>>>> worthwhile to raise are…
>>>> 
>>>> 1. What third parties, or other initiatives, are invested and/or working 
>>>> against the May deadline? and what are their views on changing it?
>>>>   1a. If we push branching back to September, how confident are we that 
>>>> we'll get to GA before the December Summit?
>>>> 2. What CEPs look like not landing by May that we consider a must-have 
>>>> this year?
>>>>   2a. Is it just tail-end commits in those CEPs that won't make it? Can 
>>>> these land (with or without a waiver) during the alpha phase?
>>>>   2b. If the final components to specified CEPs are not 
>>>> approved/appropriate to land during alpha, would it be better if the 
>>>> project commits to a one-off half-year release later in the year?
>> 

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Benjamin Lerer]

OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit
> more deliberate with releasing 5.0 and having a longer beta phase are all
> things we should consider.
>
> My 2cts,
> German
>
> *From:* Benedict 
> *Sent:* Wednesday, March 1, 2023 5:59 AM
> *To:* dev@cassandra.apache.org 
> *Subject:* [EXTERNAL] Re: [DISCUSS] Next release date
>
>
> It doesn’t look like we agreed to a policy of annual branch dates, only
> annual releases and that we would schedule this for 4.1 based on 4.0’s
> branch date. Given this was the reasoning proposed I can see why folk would
> expect this would happen for the next release. I don’t think there was a
> strong enough commitment here to be bound by, it if we think different
> maths would work better.
>
> I recall the goal for an annual cadence was to ensure we don’t have
> lengthy periods between releases like 3.x to 4.0, and to try to reduce the
> pressure certain contributors might feel to hit a specific release with a
> given feature.
>
> I think it’s better to revisit these underlying reasons and check how they
> apply than to pick a mechanism and stick to it too closely.
>
> The last release was quite recent, so we aren’t at risk of slow releases
> here. Similarly, there are some features that the *project* would probably
> benefit from landing prior to release, if this doesn’t push release back
> too far.
>
>
>
>
>
> On 1 Mar 2023, at 13:38, Mick Semb Wever  wrote:
>
> 
>
> My thoughts don't touch on CEPs inflight.
>
>
>
>
> For the sake of broadening the discussion, additional questions I think
> worthwhile to raise are…
>
> 1. What third parties, or other initiatives, are invested and/or working
> against the May deadline? and what are their views on changing it?
>   1a. If we push branching back to September, how confident are we that
> we'll get to GA before the December Summit?
> 2. What CEPs look like not landing by May that we consider a must-have
> this year?
>   2a. Is it just tail-end commits in those CEPs that won't make it? Can
> these land (with or without a waiver) during the alpha phase?
>   2b. If the final components to specified CEPs are not
> approved/appropriate to land during alpha, would it be better if the
> project commits to a one-off half-year release later in the year?
>
>
>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Josh McKenzie]

(for convenience sake, I'm referring to both Major and Minor semver releases as 
"major" in this email)

> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I would 
> advocate to delay until this has sufficient quality to be in production. 
This approach can be pretty unpredictable in this domain; often unforeseen 
things come up in implementation that can give you a long tail on something 
being production ready. For the record - I don't intend to single Accord out 
*at all* on this front, quite the opposite given how much rigor's gone into the 
design and implementation. I'm just thinking from my personal experience: 
everything I've worked on, overseen, or followed closely on this codebase 
always has a few tricks up its sleeve along the way to having edge-cases 
stabilized.

Much like on some other recent topics, I think there's a nuanced middle ground 
where we take things on a case-by-case basis. Some factors that have come up in 
this thread that resonated with me:

For a given potential release date 'X':
1. How long has it been since the last release?
2. How long do we expect qualification to take from a "freeze" (i.e. no new 
improvement or features, branch) point?
3. What body of merged production ready work is available?
4. What body of new work do we have high confidence will be ready within Y time?

I think it's worth defining a loose "minimum bound and upper bound" on release 
cycles we want to try and stick with barring extenuating circumstances. For 
instance: try not to release sooner than maybe 10 months out from a prior 
major, and try not to release later than 18 months out from a prior major. Make 
exceptions if truly exceptional things land, are about to land, or bugs are 
discovered around those boundaries.

Applying the above framework to what we have in flight, our last release date, 
expectations on CI, etc - targeting an early fall freeze (pending CEP status) 
and mid to late fall or December release "feels right" to me.

With the exception, of course, that if something merges earlier, is stable, and 
we feel is valuable enough to cut a major based on that, we do it.

~Josh

On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote:
> Hi,
> 
> We shouldn't release just for releases sake. Are there enough new features 
> and are they working well enough (quality!).
> 
> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I would 
> advocate to delay until this has sufficient quality to be in production. 
> 
> Just because something is released doesn't mean anyone is gonna use it. To 
> add some operator perspective: Every time there is a new release we need to 
> decide 
> 1) are we supporting it 
> 2) which other release can we deprecate 
> 
> and potentially migrate people - which is also a tough sell if there are no 
> significant features and/or breaking changes.  So from my perspective less 
> frequent releases are better - after all we haven't gotten around to support 
> 4.1 🙂
> 
> The 5.0 release is also coupled with deprecating  3.11 which is what a 
> significant amount of people are using - given 4.1 took longer I am not sure 
> how many people are assuming that 5 will be delayed and haven't made plans 
> (OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit more 
> deliberate with releasing 5.0 and having a longer beta phase are all things 
> we should consider.
> 
> My 2cts,
> German
> 
> *From:* Benedict 
> *Sent:* Wednesday, March 1, 2023 5:59 AM
> *To:* dev@cassandra.apache.org 
> *Subject:* [EXTERNAL] Re: [DISCUSS] Next release date
>  
> 
> It doesn’t look like we agreed to a policy of annual branch dates, only 
> annual releases and that we would schedule this for 4.1 based on 4.0’s branch 
> date. Given this was the reasoning proposed I can see why folk would expect 
> this would happen for the next release. I don’t think there was a strong 
> enough commitment here to be bound by, it if we think different maths would 
> work better.
> 
> I recall the goal for an annual cadence was to ensure we don’t have lengthy 
> periods between releases like 3.x to 4.0, and to try to reduce the pressure 
> certain contributors might feel to hit a specific release with a given 
> feature.
> 
> I think it’s better to revisit these underlying reasons and check how they 
> apply than to pick a mechanism and stick to it too closely. 
> 
> The last release was quite recent, so we aren’t at risk of slow releases 
> here. Similarly, there are some features that the *project* would probably 
> benefit from landing prior to release, if this doesn’t push release back too 
> far.
> 
> 
> 
> 
> 
>> On 1 Mar 2023, at 13:38, Mick Semb Wever  wro

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[German Eichberger via dev]

Hi,

We shouldn't release just for releases sake. Are there enough new features and 
are they working well enough (quality!).

The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I would 
advocate to delay until this has sufficient quality to be in production.

Just because something is released doesn't mean anyone is gonna use it. To add 
some operator perspective: Every time there is a new release we need to decide
1) are we supporting it
2) which other release can we deprecate

and potentially migrate people - which is also a tough sell if there are no 
significant features and/or breaking changes.  So from my perspective less 
frequent releases are better - after all we haven't gotten around to support 
4.1 🙂

The 5.0 release is also coupled with deprecating  3.11 which is what a 
significant amount of people are using - given 4.1 took longer I am not sure 
how many people are assuming that 5 will be delayed and haven't made plans 
(OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit more 
deliberate with releasing 5.0 and having a longer beta phase are all things we 
should consider.

My 2cts,
German

From: Benedict 
Sent: Wednesday, March 1, 2023 5:59 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] Next release date

It doesn’t look like we agreed to a policy of annual branch dates, only annual 
releases and that we would schedule this for 4.1 based on 4.0’s branch date. 
Given this was the reasoning proposed I can see why folk would expect this 
would happen for the next release. I don’t think there was a strong enough 
commitment here to be bound by, it if we think different maths would work 
better.

I recall the goal for an annual cadence was to ensure we don’t have lengthy 
periods between releases like 3.x to 4.0, and to try to reduce the pressure 
certain contributors might feel to hit a specific release with a given feature.

I think it’s better to revisit these underlying reasons and check how they 
apply than to pick a mechanism and stick to it too closely.

The last release was quite recent, so we aren’t at risk of slow releases here. 
Similarly, there are some features that the *project* would probably benefit 
from landing prior to release, if this doesn’t push release back too far.




On 1 Mar 2023, at 13:38, Mick Semb Wever  wrote:


My thoughts don't touch on CEPs inflight.



For the sake of broadening the discussion, additional questions I think 
worthwhile to raise are…

1. What third parties, or other initiatives, are invested and/or working 
against the May deadline? and what are their views on changing it?
  1a. If we push branching back to September, how confident are we that we'll 
get to GA before the December Summit?
2. What CEPs look like not landing by May that we consider a must-have this 
year?
  2a. Is it just tail-end commits in those CEPs that won't make it? Can these 
land (with or without a waiver) during the alpha phase?
  2b. If the final components to specified CEPs are not approved/appropriate to 
land during alpha, would it be better if the project commits to a one-off 
half-year release later in the year?

Re: [DISCUSS] Next release date

[Aleksey Yeshchenko]

Don’t need to revert it so long as the feature they are for is not enabled by 
default. Or, if it’s a bit away from being useful enough to even test - mad 
hard-disabled without a way to enable.

> On 1 Mar 2023, at 16:34, Henrik Ingo  wrote:
> 
> already merged 3 patches, but still has 2 to go? Can we allow extra time to 
> merge the last two, or do we work on reverting the first 3? (Obviously not 
> the latter...)

Re: [DISCUSS] Next release date

[David Capwell]

I am cool with defining target release date and working backwards from there.  
If we do want to go this route, I think we do need to answer why 4.1 cut -> 
release took so much time, and if people could start validation “before” we 
branch?  If we know trunk is stable today then we could release today, but I 
don’t believe we have this level of testing today, so I don’t know if I could 
say we can release in 1-4 months.

> On Mar 1, 2023, at 9:21 AM, J. D. Jordan  wrote:
> 
> We have been talking a lot about the branch cutting date, but I agree with 
> Benedict here, I think we should actually be talking about the expected 
> release date. 
> 
> If we truly believe that we can release within 1-2 months of cutting the 
> branch, and many people I have talked to think that is possible, then a May 
> branch cut means we release by July. That would only be 7 months post 4.1 
> release, that seems a little fast to me.  IIRC the last time we had release 
> cadence discussions most people were for keeping to a release cadence of 
> around 12 months, and many were against a 6 month cadence.
> 
> So if we want to have a goal of “around 12 months” and also have a goal of 
> “release before summit in December”. I would suggest we put our release date 
> goal in October to give some runway for being late and still getting out by 
> December.
> 
> So if the release date goal is October, we can also hedge with the longer 2 
> month estimate on “time after branching” to again make sure we make our 
> goals. This would put the branching in August. So if we do release in an 
> October that gives us 10 months since 4.1, which while still shorter than 12 
> much closer than only 7 months would be.
> 
> If people feel 1 month post branch cut is feasible we could cut the branch in 
> September.
> 
> -Jeremiah
> 
>> On Mar 1, 2023, at 10:34 AM, Henrik Ingo  wrote:
>> 
>> 
>> Hi 
>> 
>> Those are great questions Mick. It's good to recognize this discussion 
>> impacts a broad range of contributors and users, and not all of them might 
>> be aware of the discussion in the first place.
>> 
>> More generally I would say that your questions brought to mind two 
>> fundamental principles with a "train model" release schedule:
>> 
>>   1. If a feature isn't ready by the cut-off date, there's no reason to 
>> delay the release, because the next release is guaranteed to be just around 
>> the corner.
>>   2. If there is a really important feature that won't make it, rather than 
>> delaying the planned release, we should (also) consider the opposite: we can 
>> do the next release earlier if there is a compelling feature ready to go. 
>> (Answers question 2b from Mick.)
>> 
>> I have arguments both for and against moving the release date:
>> 
>> 
>> The to stick with the current plan, is that we have a lot of big features 
>> now landing in trunk. If we delay the release for one feature, it will delay 
>> the GA of all the other features that were ready by May. For example, while 
>> SAI code is still being massaged based on review comments, we fully expect 
>> it to merge before May. Same for the work on tries, which is on its final 
>> stretch. Arguably Java 17 support can't come soon enough either. And so 
>> on... For some user it can be a simple feature, like just one specific 
>> guardrail, that they are waiting on. So just as we are excited to wait for 
>> that one feature to be ready and make it, I'm just as unexcited about the 
>> prospect of delaying the GA of several other features. If we had just one 
>> big feature that everyone was working on, this would be easier to decide...
>> 
>> Note also that postponing the release for a single feature that is still in 
>> development is a risky bet, because you never know what unknowns are still 
>> ahead once the work is code complete and put to more serious testing. At 
>> first it might sound reasonable to delay 1-3 months, but what if on that 3rd 
>> month some unforeseen work is discovered, and now we need to discuss 
>> delaying another 3 months. Such a risk is inherent to any software project, 
>> and we should anticipate it to happen. Scott's re-telling of CASSANDRA-18110 
>> is a great example: These delays can happen due to a single issue, and it 
>> can be hard to speed things up by e.g. assigning more engineers to the work. 
>> So, when we say that we'd like to move the branching date from May to 
>> August, and specifically in order for some feature to be ready by then, what 
>> do we do if it's not ready in August?`It's presumably closer to being ready 
>> at that point, so the temptation to wait just a little bit more is always 
>> there. (And this is also my answer to Mick's question 1b.)
>> 
>> 
>> 
>> Now, let me switch to arguing the opposite opinion:
>> 
>> My instinct here would be to stick to early May as the cut-off date, but 
>> also allow for exceptions. I'm curious to hear how this proposal is 
>> received? If this was a startup, there could be a CEO or l

Re: [DISCUSS] Next release date

[J. D. Jordan]

We have been talking a lot about the branch cutting date, but I agree with Benedict here, I think we should actually be talking about the expected release date. If we truly believe that we can release within 1-2 months of cutting the branch, and many people I have talked to think that is possible, then a May branch cut means we release by July. That would only be 7 months post 4.1 release, that seems a little fast to me.  IIRC the last time we had release cadence discussions most people were for keeping to a release cadence of around 12 months, and many were against a 6 month cadence.So if we want to have a goal of “around 12 months” and also have a goal of “release before summit in December”. I would suggest we put our release date goal in October to give some runway for being late and still getting out by December.So if the release date goal is October, we can also hedge with the longer 2 month estimate on “time after branching” to again make sure we make our goals. This would put the branching in August. So if we do release in an October that gives us 10 months since 4.1, which while still shorter than 12 much closer than only 7 months would be.If people feel 1 month post branch cut is feasible we could cut the branch in September.-JeremiahOn Mar 1, 2023, at 10:34 AM, Henrik Ingo  wrote:Hi Those are great questions Mick. It's good to recognize this discussion impacts a broad range of contributors and users, and not all of them might be aware of the discussion in the first place.More generally I would say that your questions brought to mind two fundamental principles with a "train model" release schedule:  1. If a feature isn't ready by the cut-off date, there's no reason to delay the release, because the next release is guaranteed to be just around the corner.  2. If there is a really important feature that won't make it, rather than delaying the planned release, we should (also) consider the opposite: we can do the next release earlier if there is a compelling feature ready to go. (Answers question 2b from Mick.)I have arguments both for and against moving the release date:The to stick with the current plan, is that we have a lot of big features now landing in trunk. If we delay the release for one feature, it will delay the GA of all the other features that were ready by May. For example, while SAI code is still being massaged based on review comments, we fully expect it to merge before May. Same for the work on tries, which is on its final stretch. Arguably Java 17 support can't come soon enough either. And so on... For some user it can be a simple feature, like just one specific guardrail, that they are waiting on. So just as we are excited to wait for that one feature to be ready and make it, I'm just as unexcited about the prospect of delaying the GA of several other features. If we had just one big feature that everyone was working on, this would be easier to decide...Note also that postponing the release for a single feature that is still in development is a risky bet, because you never know what unknowns are still ahead once the work is code complete and put to more serious testing. At first it might sound reasonable to delay 1-3 months, but what if on that 3rd month some unforeseen work is discovered, and now we need to discuss delaying another 3 months. Such a risk is inherent to any software project, and we should anticipate it to happen. Scott's re-telling of CASSANDRA-18110 is a great example: These delays can happen due to a single issue, and it can be hard to speed things up by e.g. assigning more engineers to the work. So, when we say that we'd like to move the branching date from May to August, and specifically in order for some feature to be ready by then, what do we do if it's not ready in August?`It's presumably closer to being ready at that point, so the temptation to wait just a little bit more is always there. (And this is also my answer to Mick's question 1b.)Now, let me switch to arguing the opposite opinion:My instinct here would be to stick to early May as the cut-off date, but also allow for exceptions. I'm curious to hear how this proposal is received? If this was a startup, there could be a CEO or let's say a build manager, that could make these kind of case by case decisions expediently. But I realize in a consensus based open source project like Cassandra, we may also have to consider issues like fairness: Why would some feature be allowed a later date than others? How do we choose which work gets such exceptions?Anyway, the fact is that we have several huge bodies of work in flight now. The Accord patch was about 28k lines of code when I looked at it, and note that this doesn't even include "accord itself", which is in a different repository. SAI, Tries (independently for memtable and sstables) and UCS are all in the 10k range too. And I presume the Java 17 support and transactional metadata are the same. Each of these pieces of code represent alone years of engineerin

Re: [DISCUSS] Next release date

[Henrik Ingo]

Hi

Those are great questions Mick. It's good to recognize this discussion
impacts a broad range of contributors and users, and not all of them might
be aware of the discussion in the first place.

More generally I would say that your questions brought to mind two
fundamental principles with a "train model" release schedule:

  1. If a feature isn't ready by the cut-off date, there's no reason to
delay the release, because the next release is guaranteed to be just around
the corner.
  2. If there is a really important feature that won't make it, rather than
delaying the planned release, we should (also) consider the opposite: we
can do the next release earlier if there is a compelling feature ready to
go. (Answers question 2b from Mick.)

I have arguments both for and against moving the release date:


The to stick with the current plan, is that we have a lot of big features
now landing in trunk. If we delay the release for one feature, it will
delay the GA of all the other features that were ready by May. For example,
while SAI code is still being massaged based on review comments, we fully
expect it to merge before May. Same for the work on tries, which is on its
final stretch. Arguably Java 17 support can't come soon enough either. And
so on... For some user it can be a simple feature, like just one specific
guardrail, that they are waiting on. So just as we are excited to wait for
that one feature to be ready and make it, I'm just as unexcited about the
prospect of delaying the GA of several other features. If we had just one
big feature that everyone was working on, this would be easier to decide...

Note also that postponing the release for a single feature that is still in
development is a risky bet, because you never know what unknowns are still
ahead once the work is code complete and put to more serious testing. At
first it might sound reasonable to delay 1-3 months, but what if on that
3rd month some unforeseen work is discovered, and now we need to discuss
delaying another 3 months. Such a risk is inherent to any software project,
and we should anticipate it to happen. Scott's re-telling
of CASSANDRA-18110 is a great example: These delays can happen due to a
single issue, and it can be hard to speed things up by e.g. assigning more
engineers to the work. So, when we say that we'd like to move the branching
date from May to August, and specifically in order for some feature to be
ready by then, what do we do if it's not ready in August?`It's presumably
closer to being ready at that point, so the temptation to wait just a
little bit more is always there. (And this is also my answer to Mick's
question 1b.)



Now, let me switch to arguing the opposite opinion:

My instinct here would be to stick to early May as the cut-off date, but
also allow for exceptions. I'm curious to hear how this proposal is
received? If this was a startup, there could be a CEO or let's say a build
manager, that could make these kind of case by case decisions expediently.
But I realize in a consensus based open source project like Cassandra, we
may also have to consider issues like fairness: Why would some feature be
allowed a later date than others? How do we choose which work gets such
exceptions?

Anyway, the fact is that we have several huge bodies of work in flight now.
The Accord patch was about 28k lines of code when I looked at it, and note
that this doesn't even include "accord itself", which is in a different
repository. SAI, Tries (independently for memtable and sstables) and UCS
are all in the 10k range too. And I presume the Java 17 support and
transactional metadata are the same. Each of these pieces of code represent
alone years of engineering work. For context, Cassandra as a whole has
about 1 million lines of code. So each of these features is replacing or
adding about 1-3% of  the codebase.

With that in mind, I feel like having  a hard deadline on a single day
doesn't really serve justice to these features. In fact, most of them are
not merged in a single PR either, but  a series of PRs, each of which
independently is huge too. This makes me ask, what if some feature already
merged 3 patches, but still has 2 to go? Can we allow extra time to merge
the last two, or do we work on reverting the first 3? (Obviously not the
latter...)

So it seems to me we should keep May Xth as the beginning of the cutoff,
but where the actual cutoff is a fuzzy deadline rather than hard. For most
work it would be early may, but for the big features a few weeks or even
months of a window is ok.

This kind of flexible approach would still help advancing toward a release,
since it would quiet down the release branch significantly, and for most
contributors focus would shift to testing. (Alternatively, focus could
shift to help review and test the features that are still being worked on.)

Mick and Benjamin have been good at remind me that we can't expect to merge
all of this work the last week of April anyway. So from my point 

Re: [DISCUSS] Next release date

[Molly Monroy]


In the interest of broadening perspectives, thoughts here from two angles: 
community engagement and marketing. We will be discussing what’s coming in 
Cassandra 5.0 at Cassandra Forward in 2 weeks. This is meant to build 
excitement for the next version so having technology for folks to get their 
hands on soon after, while the news is fresh, would be advantageous for a few 
reasons...

1. From a community engagement perspective: We want to both deepen community 
engagement and build a more direct / engaged feedback loop around the release 
in the absence of an in person event (til Dec), we hope to arrange things like 
live (virtual) forums for contributors and users to weigh in on features. A May 
release would give us a runway to create these forums and time to make sure 
voices are heard through them in the lead to GA.

2. From a marketing perspective: We want to not just excite our existing 
community, but also grow as we welcome newcomers to the project. Having a new 
release out there (even in it’s early version) allows us to continue momentum, 
show consistent innovation, and work on bringing new users and contributors 
into the fold in the runway to GA.

All that said #1 could also be achieved if the project is landing features that 
will ultimately benefit the 5.0 release. These forums could be built around new 
 feature updates. 

> On Mar 1, 2023, at 6:59 AM, Benedict  wrote:
> 
> It doesn’t look like we agreed to a policy of annual branch dates, only 
> annual releases and that we would schedule this for 4.1 based on 4.0’s branch 
> date. Given this was the reasoning proposed I can see why folk would expect 
> this would happen for the next release. I don’t think there was a strong 
> enough commitment here to be bound by, it if we think different maths would 
> work better.
> 
> I recall the goal for an annual cadence was to ensure we don’t have lengthy 
> periods between releases like 3.x to 4.0, and to try to reduce the pressure 
> certain contributors might feel to hit a specific release with a given 
> feature.
> 
> I think it’s better to revisit these underlying reasons and check how they 
> apply than to pick a mechanism and stick to it too closely. 
> 
> The last release was quite recent, so we aren’t at risk of slow releases 
> here. Similarly, there are some features that the *project* would probably 
> benefit from landing prior to release, if this doesn’t push release back too 
> far.
> 
> 
> 
> 
>> On 1 Mar 2023, at 13:38, Mick Semb Wever  wrote:
>> 
>>> My thoughts don't touch on CEPs inflight. 
>> 
>> 
>> 
>> For the sake of broadening the discussion, additional questions I think 
>> worthwhile to raise are…
>> 
>> 1. What third parties, or other initiatives, are invested and/or working 
>> against the May deadline? and what are their views on changing it?
>>   1a. If we push branching back to September, how confident are we that 
>> we'll get to GA before the December Summit?
>> 2. What CEPs look like not landing by May that we consider a must-have this 
>> year?
>>   2a. Is it just tail-end commits in those CEPs that won't make it? Can 
>> these land (with or without a waiver) during the alpha phase?
>>   2b. If the final components to specified CEPs are not approved/appropriate 
>> to land during alpha, would it be better if the project commits to a one-off 
>> half-year release later in the year?

Re: [DISCUSS] Next release date

[Benedict]

It doesn’t look like we agreed to a policy of annual branch dates, only annual 
releases and that we would schedule this for 4.1 based on 4.0’s branch date. 
Given this was the reasoning proposed I can see why folk would expect this 
would happen for the next release. I don’t think there was a strong enough 
commitment here to be bound by, it if we think different maths would work 
better.

I recall the goal for an annual cadence was to ensure we don’t have lengthy 
periods between releases like 3.x to 4.0, and to try to reduce the pressure 
certain contributors might feel to hit a specific release with a given feature.

I think it’s better to revisit these underlying reasons and check how they 
apply than to pick a mechanism and stick to it too closely. 

The last release was quite recent, so we aren’t at risk of slow releases here. 
Similarly, there are some features that the *project* would probably benefit 
from landing prior to release, if this doesn’t push release back too far.




> On 1 Mar 2023, at 13:38, Mick Semb Wever  wrote:
> 
> 
>> My thoughts don't touch on CEPs inflight. 
> 
> 
> 
> For the sake of broadening the discussion, additional questions I think 
> worthwhile to raise are…
> 
> 1. What third parties, or other initiatives, are invested and/or working 
> against the May deadline? and what are their views on changing it?
>   1a. If we push branching back to September, how confident are we that we'll 
> get to GA before the December Summit?
> 2. What CEPs look like not landing by May that we consider a must-have this 
> year?
>   2a. Is it just tail-end commits in those CEPs that won't make it? Can these 
> land (with or without a waiver) during the alpha phase?
>   2b. If the final components to specified CEPs are not approved/appropriate 
> to land during alpha, would it be better if the project commits to a one-off 
> half-year release later in the year?

Re: [DISCUSS] Next release date

[Mick Semb Wever]

>
> My thoughts don't touch on CEPs inflight.
>



For the sake of broadening the discussion, additional questions I think
worthwhile to raise are…

1. What third parties, or other initiatives, are invested and/or working
against the May deadline? and what are their views on changing it?
  1a. If we push branching back to September, how confident are we that
we'll get to GA before the December Summit?
2. What CEPs look like not landing by May that we consider a must-have this
year?
  2a. Is it just tail-end commits in those CEPs that won't make it? Can
these land (with or without a waiver) during the alpha phase?
  2b. If the final components to specified CEPs are not
approved/appropriate to land during alpha, would it be better if the
project commits to a one-off half-year release later in the year?

Re: [DISCUSS] Next release date

[C. Scott Andreas]

Regarding “We should focus on why it took 6 months to go from 4.1 first alpha to GA and what happened inside that time window.” —Speaking solely from my perspective, the single biggest time draw was tracking down and resolving https://issues.apache.org/jira/browse/CASSANDRA-18110.One of the strategies we employ to validate a build is to simply run it. Reproducing and resolving this issue was a prerequisite for running the branch and performing further qualification as it blocked host replacements in mercurial circumstances. That work began prior to ApacheCon and was completed in December with continuous focus, but wasn’t something other contributors were able to reproduce (and was difficult for us, too).Inability to replace a host and run the build slowed subsequent issue-finding/fixing - in many cases past release, with bugs I think we’d have been able to find prior to 4.1.0 if we’d been able to lean harder on it (18194, 18119, 18292, probably a couple others).I do wish we’d have been able to find the cause of C-18110 faster - or at least its workaround.- ScottOn Feb 28, 2023, at 9:06 AM, Benedict  wrote:I agree, we shouldn’t be branching annually, we should be releasing annually - and we shouldn’t assume that will take six months. We should be aiming for 1-2mo and so long as our trajectory towards that is good, I don’t think there’s anything to worry about (and we’ll get our first comparative data point this release)On 28 Feb 2023, at 16:02, Ekaterina Dimitrova  wrote:By “not to have to delay again” I mean GA, not the agreement for when to branch and start feature freeze. Just to be clear as I realized I might be misunderstood :-) On Tue, 28 Feb 2023 at 10:47, Ekaterina Dimitrova  wrote:I agree that November-May falls too short so +1 on postponing the day on my endNow I think Mick brought excellent point - let’s get into separate discussion about the root cause of releasing 4.1 only in December and see what we need to change/improve on so we do not get into future delays and we do not sacrifice QA of course. “Postponing" suggests a one-off move, but I'm presuming this would be a permanent change?“I’d say move it, get to the bottom of how not to have to delay again or at least reduce the window and commitOn Tue, 28 Feb 2023 at 9:38, Mick Semb Wever  wrote:We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for 4.1 we were only able to release GA in December which impacted how much time we could spend focussing on the next release and the progress that we could do. By consequence, I am wondering if it makes sense for us to branch 5.0 in May or if we should postpone that date.What is your opinion?My initial preference is to stick with the May branch and its initial alpha/beta release. Giving in to the delays doesn't improve the causes of them.We should focus on why it took 6 months to go from 4.1 first alpha to GA and what happened inside that time window. I'm not convinced summer holidays can be to blame for. I think a lack of QA/CI and folk dedicating time to get it to GA is the bigger problem. On the QA/CI front I believe we have made significant improvements already. And we saw less releases of 4.1 before its GA. I also think reducing the focus and scope of the subsequent release cycle is a cost that creates the correct incentive, so long as we share the burden of the stabilising_to_GA journey. While it might be difficult for folk to commit their time over summer holidays, the three months of May-July should be way more than enough if we are serious about it.My thoughts don't touch on CEPs inflight. But my feeling is this should not be about what we want to "squeeze in" (which only makes the problem worse), rather whether the folk that are offering their time to stabilise to GA have a preference for May-July or their September-November."Postponing" suggests a one-off move, but I'm presuming this would be a permanent change?

Re: [DISCUSS] Next release date

[Benedict]

I agree, we shouldn’t be branching annually, we should be releasing annually - and we shouldn’t assume that will take six months. We should be aiming for 1-2mo and so long as our trajectory towards that is good, I don’t think there’s anything to worry about (and we’ll get our first comparative data point this release)On 28 Feb 2023, at 16:02, Ekaterina Dimitrova  wrote:By “not to have to delay again” I mean GA, not the agreement for when to branch and start feature freeze. Just to be clear as I realized I might be misunderstood :-) On Tue, 28 Feb 2023 at 10:47, Ekaterina Dimitrova  wrote:I agree that November-May falls too short so +1 on postponing the day on my endNow I think Mick brought excellent point - let’s get into separate discussion about the root cause of releasing 4.1 only in December and see what we need to change/improve on so we do not get into future delays and we do not sacrifice QA of course. “Postponing" suggests a one-off move, but I'm presuming this would be a permanent change?“I’d say move it, get to the bottom of how not to have to delay again or at least reduce the window and commitOn Tue, 28 Feb 2023 at 9:38, Mick Semb Wever  wrote:We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for 4.1 we were only able to release GA in December which impacted how much time we could spend focussing on the next release and the progress that we could do. By consequence, I am wondering if it makes sense for us to branch 5.0 in May or if we should postpone that date.What is your opinion?My initial preference is to stick with the May branch and its initial alpha/beta release. Giving in to the delays doesn't improve the causes of them.We should focus on why it took 6 months to go from 4.1 first alpha to GA and what happened inside that time window. I'm not convinced summer holidays can be to blame for. I think a lack of QA/CI and folk dedicating time to get it to GA is the bigger problem. On the QA/CI front I believe we have made significant improvements already. And we saw less releases of 4.1 before its GA. I also think reducing the focus and scope of the subsequent release cycle is a cost that creates the correct incentive, so long as we share the burden of the stabilising_to_GA journey. While it might be difficult for folk to commit their time over summer holidays, the three months of May-July should be way more than enough if we are serious about it.My thoughts don't touch on CEPs inflight. But my feeling is this should not be about what we want to "squeeze in" (which only makes the problem worse), rather whether the folk that are offering their time to stabilise to GA have a preference for May-July or their September-November."Postponing" suggests a one-off move, but I'm presuming this would be a permanent change?

Re: [DISCUSS] Next release date

[Ekaterina Dimitrova]

By “not to have to delay again” I mean GA, not the agreement for when to
branch and start feature freeze. Just to be clear as I realized I might be
misunderstood :-)

On Tue, 28 Feb 2023 at 10:47, Ekaterina Dimitrova 
wrote:

> I agree that November-May falls too short so +1 on postponing the day on
> my end
>
> Now I think Mick brought excellent point - let’s get into separate
> discussion about the root cause of releasing 4.1 only in December and see
> what we need to change/improve on so we do not get into future delays and
> we do not sacrifice QA of course.
>
> “Postponing" suggests a one-off move, but I'm presuming this would be a
> permanent change?“
>
> I’d say move it, get to the bottom of how not to have to delay again or at
> least reduce the window and commit
>
> On Tue, 28 Feb 2023 at 9:38, Mick Semb Wever  wrote:
>
>> We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for
>>> 4.1 we were only able to release GA in December which impacted how much
>>> time we could spend focussing on the next release and the progress that we
>>> could do. By consequence, I am wondering if it makes sense for us to branch
>>> 5.0 in May or if we should postpone that date.
>>>
>>> What is your opinion?
>>>
>>
>>
>> My initial preference is to stick with the May branch and its initial
>> alpha/beta release.
>>
>> Giving in to the delays doesn't improve the causes of them.
>>
>> We should focus on why it took 6 months to go from 4.1 first alpha to GA
>> and what happened inside that time window. I'm not convinced summer
>> holidays can be to blame for. I think a lack of QA/CI and folk dedicating
>> time to get it to GA is the bigger problem.
>>
>> On the QA/CI front I believe we have made significant improvements
>> already. And we saw less releases of 4.1 before its GA. I also think
>> reducing the focus and scope of the subsequent release cycle is a cost that
>> creates the correct incentive, so long as we share the burden of the
>> stabilising_to_GA journey. While it might be difficult for folk to commit
>> their time over summer holidays, the three months of May-July should be way
>> more than enough if we are serious about it.
>>
>> My thoughts don't touch on CEPs inflight. But my feeling is this should
>> not be about what we want to "squeeze in" (which only makes the problem
>> worse), rather whether the folk that are offering their time to stabilise
>> to GA have a preference for May-July or their September-November.
>>
>> "Postponing" suggests a one-off move, but I'm presuming this would be a
>> permanent change?
>>
>>
>>

Re: [DISCUSS] Next release date

[Ekaterina Dimitrova]

I agree that November-May falls too short so +1 on postponing the day on my
end

Now I think Mick brought excellent point - let’s get into separate
discussion about the root cause of releasing 4.1 only in December and see
what we need to change/improve on so we do not get into future delays and
we do not sacrifice QA of course.

“Postponing" suggests a one-off move, but I'm presuming this would be a
permanent change?“

I’d say move it, get to the bottom of how not to have to delay again or at
least reduce the window and commit

On Tue, 28 Feb 2023 at 9:38, Mick Semb Wever  wrote:

> We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for
>> 4.1 we were only able to release GA in December which impacted how much
>> time we could spend focussing on the next release and the progress that we
>> could do. By consequence, I am wondering if it makes sense for us to branch
>> 5.0 in May or if we should postpone that date.
>>
>> What is your opinion?
>>
>
>
> My initial preference is to stick with the May branch and its initial
> alpha/beta release.
>
> Giving in to the delays doesn't improve the causes of them.
>
> We should focus on why it took 6 months to go from 4.1 first alpha to GA
> and what happened inside that time window. I'm not convinced summer
> holidays can be to blame for. I think a lack of QA/CI and folk dedicating
> time to get it to GA is the bigger problem.
>
> On the QA/CI front I believe we have made significant improvements
> already. And we saw less releases of 4.1 before its GA. I also think
> reducing the focus and scope of the subsequent release cycle is a cost that
> creates the correct incentive, so long as we share the burden of the
> stabilising_to_GA journey. While it might be difficult for folk to commit
> their time over summer holidays, the three months of May-July should be way
> more than enough if we are serious about it.
>
> My thoughts don't touch on CEPs inflight. But my feeling is this should
> not be about what we want to "squeeze in" (which only makes the problem
> worse), rather whether the folk that are offering their time to stabilise
> to GA have a preference for May-July or their September-November.
>
> "Postponing" suggests a one-off move, but I'm presuming this would be a
> permanent change?
>
>
>

Re: [DISCUSS] Next release date

[Mick Semb Wever]

>
> We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for
> 4.1 we were only able to release GA in December which impacted how much
> time we could spend focussing on the next release and the progress that we
> could do. By consequence, I am wondering if it makes sense for us to branch
> 5.0 in May or if we should postpone that date.
>
> What is your opinion?
>


My initial preference is to stick with the May branch and its initial
alpha/beta release.

Giving in to the delays doesn't improve the causes of them.

We should focus on why it took 6 months to go from 4.1 first alpha to GA
and what happened inside that time window. I'm not convinced summer
holidays can be to blame for. I think a lack of QA/CI and folk dedicating
time to get it to GA is the bigger problem.

On the QA/CI front I believe we have made significant improvements already.
And we saw less releases of 4.1 before its GA. I also think reducing the
focus and scope of the subsequent release cycle is a cost that creates the
correct incentive, so long as we share the burden of the stabilising_to_GA
journey. While it might be difficult for folk to commit their time over
summer holidays, the three months of May-July should be way more than
enough if we are serious about it.

My thoughts don't touch on CEPs inflight. But my feeling is this should not
be about what we want to "squeeze in" (which only makes the problem worse),
rather whether the folk that are offering their time to stabilise to GA
have a preference for May-July or their September-November.

"Postponing" suggests a one-off move, but I'm presuming this would be a
permanent change?

Re: [DISCUSS] Next release date

[J. D. Jordan]

I think it makes sense to plan on cutting the branch later given when 4.1 
actually released. I would suggest either August or September as a good time to 
cut the branch, at the end of the summer.

-Jeremiah

> On Feb 28, 2023, at 7:42 AM, Benjamin Lerer  wrote:
> 
> 
> Hi,
> 
> We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for 4.1 
> we were only able to release GA in December which impacted how much time we 
> could spend focussing on the next release and the progress that we could do. 
> By consequence, I am wondering if it makes sense for us to branch 5.0 in May 
> or if we should postpone that date.
> 
> What is your opinion?
> 
> Benjamin

[DISCUSS] Next release date

[Benjamin Lerer]

Hi,

We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for 4.1
we were only able to release GA in December which impacted how much time we
could spend focussing on the next release and the progress that we could
do. By consequence, I am wondering if it makes sense for us to branch 5.0
in May or if we should postpone that date.

What is your opinion?

Benjamin