You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Benjamin Lerer <bl...@apache.org> on 2023/02/28 13:42:19 UTC
[DISCUSS] Next release date
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
Re: [DISCUSS] Next release date
Posted by "C. Scott Andreas" <sc...@paradoxica.net>.
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.
\- Scott
> On Feb 28, 2023, at 9:06 AM, Benedict <be...@apache.org> 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 <e....@gmail.com>
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
<[e.dimitrova@gmail.com](mailto:e.dimitrova@gmail.com)> 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
<[mck@apache.org](mailto:mck@apache.org)> 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
Posted by Benedict <be...@apache.org>.
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 <e....@gmail.com> 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
> <[e.dimitrova@gmail.com](mailto:e.dimitrova@gmail.com)> 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
<[mck@apache.org](mailto:mck@apache.org)> 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
Posted by Ekaterina Dimitrova <e....@gmail.com>.
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 <e....@gmail.com>
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 <mc...@apache.org> 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
Posted by Ekaterina Dimitrova <e....@gmail.com>.
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 <mc...@apache.org> 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: [EXTERNAL] Re: [DISCUSS] Next release date
Posted by Ekaterina Dimitrova <e....@gmail.com>.
Getting JDK17 far enough to drop JDK8 eta is end of May to June. Blockers
to dropping JDK8 are listed against CASSANDRA-18255. Production ready JDK17
support remains a bigger unknown task, which we need more help on.
On Mon, 13 Mar 2023 at 8:48, Berenguer Blasi <be...@gmail.com>
wrote:
> TTL (CASSANDRA-14227) is undergoing review and it's in final stages afaik.
> A big rebase and perf re-testing will be needed to confirm all is still
> good. I would expect this to happen this month.
>
> Then the feature flag and downgradability issue, which are unkown atm in
> terms of complexity, are next.
> On 13/3/23 12:34, Mike Adamson wrote:
>
> CEP-7 Storage Attached Index is in review with ~430 files and ~70k LOC.
> The bulk of the project is in 3 main patches. The first patch (in-memory
> index and query path) is merged to the feature branch CASSANDRA-16052 and
> the second patch (on-disk write and literal / string index) is in review.
>
> Mike
>
> On Thu, 9 Mar 2023 at 09:13, Branimir Lambov <bl...@apache.org> wrote:
>
>> CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy)
>> should both be ready for review by mid-April.
>>
>> Both are around 10k LOC, fairly isolated, and in need of a committer to
>> review.
>>
>> Regards,
>> Branimir
>>
>> On Mon, Mar 6, 2023 at 11:25 AM Benjamin Lerer <b....@gmail.com> wrote:
>>
>>> Sorry, I realized that when I started the discussion I probably did not
>>> frame it enough as I see that it is now going into different directions.
>>> The concerns I am seeing are:
>>> 1) A too small amount of time between releases is inefficient from a
>>> development perspective and from a user perspective. From a development
>>> point of view because we are missing time to deliver some features. From a
>>> user perspective because they cannot follow with the upgrade.
>>> 2) Some features are so anticipated (Accord being the one mentioned)
>>> that people would prefer to delay the release to make sure that it is
>>> available as soon as possible.
>>> 3) We do not know how long we need to go from the freeze to GA. We hope
>>> for 2 months but our last experience was 6 months. So delaying the release
>>> could mean not releasing this year.
>>> 4) For people doing marketing it is really hard to promote a product
>>> when you do not know when the release will come and what features might be
>>> there.
>>>
>>> All those concerns are probably even made worse by the fact that we do
>>> not have a clear visibility on where we are.
>>>
>>> Should we clarify that part first by getting an idea of the status of
>>> the different CEPs and other big pieces of work? From there we could agree
>>> on some timeline for the freeze. We could then discuss how to make
>>> predictable the time from freeze to GA.
>>>
>>>
>>>
>>> Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jm...@apache.org> a
>>> écrit :
>>>
>>>> (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 <be...@apache.org>
>>>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>>>> *To:* dev@cassandra.apache.org <de...@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 <mc...@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?
>>>>
>>>>
>>>>
>
> --
> [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
Posted by Berenguer Blasi <be...@gmail.com>.
TTL (CASSANDRA-14227) is undergoing review and it's in final stages
afaik. A big rebase and perf re-testing will be needed to confirm all is
still good. I would expect this to happen this month.
Then the feature flag and downgradability issue, which are unkown atm in
terms of complexity, are next.
On 13/3/23 12:34, Mike Adamson wrote:
> CEP-7 Storage Attached Index is in review with ~430 files and ~70k
> LOC. The bulk of the project is in 3 main patches. The first patch
> (in-memory index and query path) is merged to the feature branch
> CASSANDRA-16052 and the second patch (on-disk write and literal /
> string index) is in review.
>
> Mike
>
> On Thu, 9 Mar 2023 at 09:13, Branimir Lambov <bl...@apache.org> wrote:
>
> CEPs 25 (trie-indexed sstables) and 26 (unified compaction
> strategy) should both be ready for review by mid-April.
>
> Both are around 10k LOC, fairly isolated, and in need of a
> committer to review.
>
> Regards,
> Branimir
>
> On Mon, Mar 6, 2023 at 11:25 AM Benjamin Lerer <b....@gmail.com>
> wrote:
>
> Sorry, I realized that when I started the discussion I
> probably did not frame it enough as I see that it is now going
> into different directions.
> The concerns I am seeing are:
> 1) A too small amount of time between releases is inefficient
> from a development perspective and from a user perspective.
> From a development point of view because we are missing time
> to deliver some features. From a user perspective because they
> cannot follow with the upgrade.
> 2) Some features are so anticipated (Accord being the one
> mentioned) that people would prefer to delay the release to
> make sure that it is available as soon as possible.
> 3) We do not know how long we need to go from the freeze to
> GA. We hope for 2 months but our last experience was 6 months.
> So delaying the release could mean not releasing this year.
> 4) For people doing marketing it is really hard to promote a
> product when you do not know when the release will come and
> what features might be there.
>
> All those concerns are probably even made worse by the fact
> that we do not have a clear visibility on where we are.
>
> Should we clarify that part first by getting an idea of the
> status of the different CEPs and other big pieces of work?
> From there we could agree on some timeline for the freeze. We
> could then discuss how to make predictable the time from
> freeze to GA.
>
>
>
> Le sam. 4 mars 2023 à 18:14, Josh McKenzie
> <jm...@apache.org> a écrit :
>
> (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 <be...@apache.org>
>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>> *To:* dev@cassandra.apache.org <de...@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
>>> <mc...@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 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 <tel:16503896000>|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/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=>
> Twitter Logo <https://twitter.com/DataStax> RSS Feed
> <https://www.datastax.com/blog/rss.xml> Github Logo
> <https://github.com/datastax>
>
Re: [EXTERNAL] [DISCUSS] Next release date
Posted by "J. D. Jordan" <je...@gmail.com>.
That was my understanding as well.
> On Mar 30, 2023, at 11:21 AM, Josh McKenzie <jm...@apache.org> 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, 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
<[henrik.ingo@datastax.com](mailto:henrik.ingo@datastax.com)> 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.jordan@gmail.com](mailto:jeremiah.jordan@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
<[jmckenzie@apache.org](mailto:jmckenzie@apache.org)> 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
<[blerer@apache.org](mailto:blerer@apache.org)> 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
<[pauloricardomg@gmail.com](mailto:pauloricardomg@gmail.com)> 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
<[mck@apache.org](mailto:mck@apache.org)> 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](http://www.datastax.com)_
>
>>>
>>> [ __](https://urldefense.com/v3/__https://www.facebook.com/datastax__;!!PbtH5S7Ebw!YwUujv3MRrmq_ipPhlZL-9i-mcA7vVv2zonpirMyQRgneNHVbR57HKz1a_P-
JjfUMrkWX7bRF282xzBt3qPS$)
[__](https://twitter.com/datastax)
[__](https://urldefense.com/v3/__https://www.linkedin.com/company/datastax/__;!!PbtH5S7Ebw!YwUujv3MRrmq_ipPhlZL-9i-mcA7vVv2zonpirMyQRgneNHVbR57HKz1a_P-
JjfUMrkWX7bRF282xwlf4tqE$)
[__](https://github.com/datastax/)
>
>>>
>>> ---|---
>
>
>
Re: [DISCUSS] Next release date
Posted by Josh McKenzie <jm...@apache.org>.
> 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 <jm...@apache.org> 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
Posted by Caleb Rackliffe <ca...@gmail.com>.
> 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 <jm...@apache.org> 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
Posted by Josh McKenzie <jm...@apache.org>.
> 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
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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
Posted by Benedict <be...@apache.org>.
> 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 <he...@datastax.com> 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](https://github.com/datastax/cassandra/commits/ds-trunk).
>
> 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](http://www.datastax.com)
>
> [](https://www.facebook.com/datastax)
> [](https://twitter.com/datastax)
> [](https://www.linkedin.com/company/datastax/)
> [](https://github.com/datastax/)
>
>
>
> ---|---
Re: [DISCUSS] Next release date
Posted by Caleb Rackliffe <ca...@gmail.com>.
> 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 <he...@datastax.com>
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 <he...@datastax.com>
> 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
>> <https://github.com/datastax/cassandra/commits/ds-trunk>.
>> 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
>>
>> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
>> <https://www.linkedin.com/company/datastax/>
>> <https://github.com/datastax/>
>>
>>
>
> --
>
> Henrik Ingo
>
> c. +358 40 569 7354
>
> w. www.datastax.com
>
> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
> <https://www.linkedin.com/company/datastax/>
> <https://github.com/datastax/>
>
>
Re: [DISCUSS] Next release date
Posted by Henrik Ingo <he...@datastax.com>.
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 <he...@datastax.com>
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 <https://github.com/datastax/cassandra/commits/ds-trunk>
> .
> 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
>
> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
> <https://www.linkedin.com/company/datastax/>
> <https://github.com/datastax/>
>
>
--
Henrik Ingo
c. +358 40 569 7354
w. www.datastax.com
<https://www.facebook.com/datastax> <https://twitter.com/datastax>
<https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
Re: [DISCUSS] Next release date
Posted by Henrik Ingo <he...@datastax.com>.
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 <https://github.com/datastax/cassandra/commits/ds-trunk>.
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
<https://www.facebook.com/datastax> <https://twitter.com/datastax>
<https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
Re: [DISCUSS] Next release date
Posted by Josh McKenzie <jm...@apache.org>.
> 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
Posted by Mick Semb Wever <mc...@apache.org>.
> 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
Posted by Caleb Rackliffe <ca...@gmail.com>.
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 <jm...@apache.org> 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 <ca...@gmail.com>
> 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 <ca...@gmail.com>
> 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
Posted by Josh McKenzie <jm...@apache.org>.
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 <ca...@gmail.com> 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 <ca...@gmail.com> 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
Posted by Josh McKenzie <jm...@apache.org>.
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 <ca...@gmail.com> 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 <ca...@gmail.com> 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
Posted by Mick Semb Wever <mc...@apache.org>.
On Mon, 17 Apr 2023 at 19:31, Caleb Rackliffe <ca...@gmail.com>
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 <ca...@gmail.com>
> 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
Posted by Caleb Rackliffe <ca...@gmail.com>.
...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 <ca...@gmail.com>
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 <mc...@apache.org> 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
Posted by Caleb Rackliffe <ca...@gmail.com>.
> 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 <mc...@apache.org> 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
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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
Posted by Josh McKenzie <jm...@apache.org>.
> 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
Posted by Mick Semb Wever <mc...@apache.org>.
>
>> 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
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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
Posted by Josh McKenzie <jm...@apache.org>.
> 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
Posted by Mick Semb Wever <mc...@apache.org>.
> 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
Posted by Josh McKenzie <jm...@apache.org>.
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 <he...@datastax.com> 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 <je...@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 <jm...@apache.org> 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 <bl...@apache.org> 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 <pa...@gmail.com> 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 <mc...@apache.org> 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_
>>
>> __ <https://www.facebook.com/datastax> __ <https://twitter.com/datastax> __ <https://www.linkedin.com/company/datastax/> __ <https://github.com/datastax/>
>>
Re: [EXTERNAL] [DISCUSS] Next release date
Posted by Benjamin Lerer <b....@gmail.com>.
>
> 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 <he...@datastax.com> 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.jordan@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 <jm...@apache.org> 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 <bl...@apache.org> 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 <pa...@gmail.com> 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 <mc...@apache.org>
>> 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
>
> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
> <https://www.linkedin.com/company/datastax/>
> <https://github.com/datastax/>
>
>
Re: [EXTERNAL] [DISCUSS] Next release date
Posted by Henrik Ingo <he...@datastax.com>.
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 <je...@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 <jm...@apache.org> 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 <bl...@apache.org> 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 <pa...@gmail.com> 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 <mc...@apache.org> 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
<https://www.facebook.com/datastax> <https://twitter.com/datastax>
<https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
Re: [EXTERNAL] [DISCUSS] Next release date
Posted by Josh McKenzie <jm...@apache.org>.
> 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 <b....@gmail.com> 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 <ca...@gmail.com> 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 <bl...@apache.org> 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 <je...@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 <jm...@apache.org> 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 <bl...@apache.org> 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 <pa...@gmail.com> 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 <mc...@apache.org> 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
Posted by Caleb Rackliffe <ca...@gmail.com>.
> 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 <b....@gmail.com> 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 <ca...@gmail.com>
> 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 <bl...@apache.org>
>> 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.jordan@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 <jm...@apache.org>
>>>> 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 <bl...@apache.org>
>>>> 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 <pa...@gmail.com>
>>>> 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 <mc...@apache.org>
>>>> 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
Posted by Benjamin Lerer <b....@gmail.com>.
>
> 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 <ca...@gmail.com> 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 <bl...@apache.org> 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.jordan@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 <jm...@apache.org> 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 <bl...@apache.org>
>>> 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 <pa...@gmail.com>
>>> 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 <mc...@apache.org>
>>> 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
Posted by Caleb Rackliffe <ca...@gmail.com>.
> 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 <bl...@apache.org> 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 <je...@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 <jm...@apache.org> 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 <bl...@apache.org> 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 <pa...@gmail.com> 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 <mc...@apache.org>
>> 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
Posted by Benjamin Lerer <bl...@apache.org>.
>
> 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 <je...@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 <jm...@apache.org> 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 <bl...@apache.org> 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 <pa...@gmail.com> 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 <mc...@apache.org> 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
Posted by Jeremiah D Jordan <je...@gmail.com>.
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 <jm...@apache.org> 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 <blerer@apache.org <ma...@apache.org>> 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 <pauloricardomg@gmail.com <ma...@gmail.com>> 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 <mck@apache.org <ma...@apache.org>> 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
Posted by Josh McKenzie <jm...@apache.org>.
> 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 <bl...@apache.org> 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 <pa...@gmail.com> 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 <mc...@apache.org> 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
Posted by Brandon Williams <dr...@gmail.com>.
I am +1 on a 5.0 branch freeze.
Kind Regards,
Brandon
On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer <bl...@apache.org> 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 <pa...@gmail.com> 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 <mc...@apache.org> 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
Posted by Benjamin Lerer <bl...@apache.org>.
>
> 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 <pa...@gmail.com> 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 <mc...@apache.org> 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
Posted by Paulo Motta <pa...@gmail.com>.
> 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 <mc...@apache.org> 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
Posted by Mick Semb Wever <mc...@apache.org>.
> 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
Posted by Benjamin Lerer <bl...@apache.org>.
Thanks everybody for the feedback.
It seems to me that considering that Accord (CEP-15) depends on
Transactional Cluster Metadata (CEP-21) and that, according to Sam, CEP-21
could land late July/August, Accord will probably not be fully merged
before late August/September.
That brings us quite late in the year and exposes us to the risk of not
releasing this year. Therefore, I wonder if we should not slightly change
the way we approach the release this year to minimize the risk of not
releasing this year while getting a 5.0 version with all the most
anticipated features.
I would like to propose a partial freeze of 5.0 in June. At which point we
could expect, based on people's feedback, most CEPs and big features,
outside of CEP-21 and CEP-15, to have been committed to trunk. This partial
freeze will be valid for every new feature except CEP-21 and CEP-15. That
approach will allow us to start stabilizing the 5.0 branch before the 2
CEPs are merged and it will also prevent the goal post from moving.
Reducing the time needed to release after the merge.
What do you think?
Le jeu. 16 mars 2023 à 12:38, Mike Adamson <ma...@datastax.com> a écrit :
> Sorry, I realised that I hadn't included any completion date for CEP-7. At
> the current time we are looking at completion mid to end of April.
>
> Mike
>
> On Mon, 13 Mar 2023 at 11:34, Mike Adamson <ma...@datastax.com> wrote:
>
>> CEP-7 Storage Attached Index is in review with ~430 files and ~70k LOC.
>> The bulk of the project is in 3 main patches. The first patch (in-memory
>> index and query path) is merged to the feature branch CASSANDRA-16052 and
>> the second patch (on-disk write and literal / string index) is in review.
>>
>> Mike
>>
>> On Thu, 9 Mar 2023 at 09:13, Branimir Lambov <bl...@apache.org> wrote:
>>
>>> CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy)
>>> should both be ready for review by mid-April.
>>>
>>> Both are around 10k LOC, fairly isolated, and in need of a committer to
>>> review.
>>>
>>> Regards,
>>> Branimir
>>>
>>> On Mon, Mar 6, 2023 at 11:25 AM Benjamin Lerer <b....@gmail.com>
>>> wrote:
>>>
>>>> Sorry, I realized that when I started the discussion I probably did not
>>>> frame it enough as I see that it is now going into different directions.
>>>> The concerns I am seeing are:
>>>> 1) A too small amount of time between releases is inefficient from a
>>>> development perspective and from a user perspective. From a development
>>>> point of view because we are missing time to deliver some features. From a
>>>> user perspective because they cannot follow with the upgrade.
>>>> 2) Some features are so anticipated (Accord being the one mentioned)
>>>> that people would prefer to delay the release to make sure that it is
>>>> available as soon as possible.
>>>> 3) We do not know how long we need to go from the freeze to GA. We hope
>>>> for 2 months but our last experience was 6 months. So delaying the release
>>>> could mean not releasing this year.
>>>> 4) For people doing marketing it is really hard to promote a product
>>>> when you do not know when the release will come and what features might be
>>>> there.
>>>>
>>>> All those concerns are probably even made worse by the fact that we do
>>>> not have a clear visibility on where we are.
>>>>
>>>> Should we clarify that part first by getting an idea of the status of
>>>> the different CEPs and other big pieces of work? From there we could agree
>>>> on some timeline for the freeze. We could then discuss how to make
>>>> predictable the time from freeze to GA.
>>>>
>>>>
>>>>
>>>> Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jm...@apache.org> a
>>>> écrit :
>>>>
>>>>> (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 <be...@apache.org>
>>>>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>>>>> *To:* dev@cassandra.apache.org <de...@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 <mc...@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?
>>>>>
>>>>>
>>>>>
>>
>> --
>> [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>
>>
>>
>
> --
> [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
Posted by Mike Adamson <ma...@datastax.com>.
Sorry, I realised that I hadn't included any completion date for CEP-7. At
the current time we are looking at completion mid to end of April.
Mike
On Mon, 13 Mar 2023 at 11:34, Mike Adamson <ma...@datastax.com> wrote:
> CEP-7 Storage Attached Index is in review with ~430 files and ~70k LOC.
> The bulk of the project is in 3 main patches. The first patch (in-memory
> index and query path) is merged to the feature branch CASSANDRA-16052 and
> the second patch (on-disk write and literal / string index) is in review.
>
> Mike
>
> On Thu, 9 Mar 2023 at 09:13, Branimir Lambov <bl...@apache.org> wrote:
>
>> CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy)
>> should both be ready for review by mid-April.
>>
>> Both are around 10k LOC, fairly isolated, and in need of a committer to
>> review.
>>
>> Regards,
>> Branimir
>>
>> On Mon, Mar 6, 2023 at 11:25 AM Benjamin Lerer <b....@gmail.com> wrote:
>>
>>> Sorry, I realized that when I started the discussion I probably did not
>>> frame it enough as I see that it is now going into different directions.
>>> The concerns I am seeing are:
>>> 1) A too small amount of time between releases is inefficient from a
>>> development perspective and from a user perspective. From a development
>>> point of view because we are missing time to deliver some features. From a
>>> user perspective because they cannot follow with the upgrade.
>>> 2) Some features are so anticipated (Accord being the one mentioned)
>>> that people would prefer to delay the release to make sure that it is
>>> available as soon as possible.
>>> 3) We do not know how long we need to go from the freeze to GA. We hope
>>> for 2 months but our last experience was 6 months. So delaying the release
>>> could mean not releasing this year.
>>> 4) For people doing marketing it is really hard to promote a product
>>> when you do not know when the release will come and what features might be
>>> there.
>>>
>>> All those concerns are probably even made worse by the fact that we do
>>> not have a clear visibility on where we are.
>>>
>>> Should we clarify that part first by getting an idea of the status of
>>> the different CEPs and other big pieces of work? From there we could agree
>>> on some timeline for the freeze. We could then discuss how to make
>>> predictable the time from freeze to GA.
>>>
>>>
>>>
>>> Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jm...@apache.org> a
>>> écrit :
>>>
>>>> (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 <be...@apache.org>
>>>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>>>> *To:* dev@cassandra.apache.org <de...@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 <mc...@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?
>>>>
>>>>
>>>>
>
> --
> [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>
>
>
--
[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
Posted by Mike Adamson <ma...@datastax.com>.
CEP-7 Storage Attached Index is in review with ~430 files and ~70k LOC. The
bulk of the project is in 3 main patches. The first patch (in-memory index
and query path) is merged to the feature branch CASSANDRA-16052 and the
second patch (on-disk write and literal / string index) is in review.
Mike
On Thu, 9 Mar 2023 at 09:13, Branimir Lambov <bl...@apache.org> wrote:
> CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy)
> should both be ready for review by mid-April.
>
> Both are around 10k LOC, fairly isolated, and in need of a committer to
> review.
>
> Regards,
> Branimir
>
> On Mon, Mar 6, 2023 at 11:25 AM Benjamin Lerer <b....@gmail.com> wrote:
>
>> Sorry, I realized that when I started the discussion I probably did not
>> frame it enough as I see that it is now going into different directions.
>> The concerns I am seeing are:
>> 1) A too small amount of time between releases is inefficient from a
>> development perspective and from a user perspective. From a development
>> point of view because we are missing time to deliver some features. From a
>> user perspective because they cannot follow with the upgrade.
>> 2) Some features are so anticipated (Accord being the one mentioned) that
>> people would prefer to delay the release to make sure that it is available
>> as soon as possible.
>> 3) We do not know how long we need to go from the freeze to GA. We hope
>> for 2 months but our last experience was 6 months. So delaying the release
>> could mean not releasing this year.
>> 4) For people doing marketing it is really hard to promote a product when
>> you do not know when the release will come and what features might be there.
>>
>> All those concerns are probably even made worse by the fact that we do
>> not have a clear visibility on where we are.
>>
>> Should we clarify that part first by getting an idea of the status of the
>> different CEPs and other big pieces of work? From there we could agree on
>> some timeline for the freeze. We could then discuss how to make predictable
>> the time from freeze to GA.
>>
>>
>>
>> Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jm...@apache.org> a
>> écrit :
>>
>>> (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 <be...@apache.org>
>>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>>> *To:* dev@cassandra.apache.org <de...@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 <mc...@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?
>>>
>>>
>>>
--
[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
Posted by Andrés de la Peña <ad...@apache.org>.
>
> 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 <mc...@apache.org> 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
Posted by Mick Semb Wever <mc...@apache.org>.
> > > 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
Posted by Josh McKenzie <jm...@apache.org>.
> 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
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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
Posted by Ekaterina Dimitrova <e....@gmail.com>.
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 <jm...@apache.org> 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
Posted by Josh McKenzie <jm...@apache.org>.
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
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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
Posted by Maxim Muzafarov <mm...@apache.org>.
When I was a release manager for another Apache project, I found it
useful to create confluence pages for the upcoming release, both for
transparency of release dates and for benchmarks. Of course, the dates
can be updated when we will have a better understanding of the scope
of the release.
Do we want something similar?
Here is an example:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10
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
Example:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=546
On Thu, 9 Mar 2023 at 10:13, Branimir Lambov <bl...@apache.org> wrote:
>
> CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy) should both be ready for review by mid-April.
>
> Both are around 10k LOC, fairly isolated, and in need of a committer to review.
>
> Regards,
> Branimir
>
> On Mon, Mar 6, 2023 at 11:25 AM Benjamin Lerer <b....@gmail.com> wrote:
>>
>> Sorry, I realized that when I started the discussion I probably did not frame it enough as I see that it is now going into different directions.
>> The concerns I am seeing are:
>> 1) A too small amount of time between releases is inefficient from a development perspective and from a user perspective. From a development point of view because we are missing time to deliver some features. From a user perspective because they cannot follow with the upgrade.
>> 2) Some features are so anticipated (Accord being the one mentioned) that people would prefer to delay the release to make sure that it is available as soon as possible.
>> 3) We do not know how long we need to go from the freeze to GA. We hope for 2 months but our last experience was 6 months. So delaying the release could mean not releasing this year.
>> 4) For people doing marketing it is really hard to promote a product when you do not know when the release will come and what features might be there.
>>
>> All those concerns are probably even made worse by the fact that we do not have a clear visibility on where we are.
>>
>> Should we clarify that part first by getting an idea of the status of the different CEPs and other big pieces of work? From there we could agree on some timeline for the freeze. We could then discuss how to make predictable the time from freeze to GA.
>>
>>
>>
>> Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jm...@apache.org> a écrit :
>>>
>>> (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 <be...@apache.org>
>>> Sent: Wednesday, March 1, 2023 5:59 AM
>>> To: dev@cassandra.apache.org <de...@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 <mc...@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
Posted by Branimir Lambov <bl...@apache.org>.
CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy) should
both be ready for review by mid-April.
Both are around 10k LOC, fairly isolated, and in need of a committer to
review.
Regards,
Branimir
On Mon, Mar 6, 2023 at 11:25 AM Benjamin Lerer <b....@gmail.com> wrote:
> Sorry, I realized that when I started the discussion I probably did not
> frame it enough as I see that it is now going into different directions.
> The concerns I am seeing are:
> 1) A too small amount of time between releases is inefficient from a
> development perspective and from a user perspective. From a development
> point of view because we are missing time to deliver some features. From a
> user perspective because they cannot follow with the upgrade.
> 2) Some features are so anticipated (Accord being the one mentioned) that
> people would prefer to delay the release to make sure that it is available
> as soon as possible.
> 3) We do not know how long we need to go from the freeze to GA. We hope
> for 2 months but our last experience was 6 months. So delaying the release
> could mean not releasing this year.
> 4) For people doing marketing it is really hard to promote a product when
> you do not know when the release will come and what features might be there.
>
> All those concerns are probably even made worse by the fact that we do not
> have a clear visibility on where we are.
>
> Should we clarify that part first by getting an idea of the status of the
> different CEPs and other big pieces of work? From there we could agree on
> some timeline for the freeze. We could then discuss how to make predictable
> the time from freeze to GA.
>
>
>
> Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jm...@apache.org> a
> écrit :
>
>> (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 <be...@apache.org>
>> *Sent:* Wednesday, March 1, 2023 5:59 AM
>> *To:* dev@cassandra.apache.org <de...@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 <mc...@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] [DISCUSS] Next release date
Posted by Mick Semb Wever <mc...@apache.org>.
On Tue, 7 Mar 2023 at 11:20, Sam Tunnicliffe <sa...@beobal.com> 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
Posted by Sam Tunnicliffe <sa...@beobal.com>.
Currently, we anticipate CEP-21 being in a mergeable state around late July/August. We're intending to push a feature branch with an implementation covering much of the core functionality to the ASF repo this week. Doing so will obviously help us get a better idea of the remaining work as we incorporate feedback from the community and to document that outstanding effort more clearly.
> On 6 Mar 2023, at 09:24, Benjamin Lerer <b....@gmail.com> wrote:
>
> Sorry, I realized that when I started the discussion I probably did not frame it enough as I see that it is now going into different directions.
> The concerns I am seeing are:
> 1) A too small amount of time between releases is inefficient from a development perspective and from a user perspective. From a development point of view because we are missing time to deliver some features. From a user perspective because they cannot follow with the upgrade.
> 2) Some features are so anticipated (Accord being the one mentioned) that people would prefer to delay the release to make sure that it is available as soon as possible.
> 3) We do not know how long we need to go from the freeze to GA. We hope for 2 months but our last experience was 6 months. So delaying the release could mean not releasing this year.
> 4) For people doing marketing it is really hard to promote a product when you do not know when the release will come and what features might be there.
>
> All those concerns are probably even made worse by the fact that we do not have a clear visibility on where we are.
>
> Should we clarify that part first by getting an idea of the status of the different CEPs and other big pieces of work? From there we could agree on some timeline for the freeze. We could then discuss how to make predictable the time from freeze to GA.
>
>
>
> Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jmckenzie@apache.org <ma...@apache.org>> a écrit :
>> (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 <benedict@apache.org <ma...@apache.org>>
>>> Sent: Wednesday, March 1, 2023 5:59 AM
>>> To: dev@cassandra.apache.org <ma...@cassandra.apache.org> <dev@cassandra.apache.org <ma...@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 <mck@apache.org <ma...@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
Posted by Benjamin Lerer <b....@gmail.com>.
Sorry, I realized that when I started the discussion I probably did not
frame it enough as I see that it is now going into different directions.
The concerns I am seeing are:
1) A too small amount of time between releases is inefficient from a
development perspective and from a user perspective. From a development
point of view because we are missing time to deliver some features. From a
user perspective because they cannot follow with the upgrade.
2) Some features are so anticipated (Accord being the one mentioned) that
people would prefer to delay the release to make sure that it is available
as soon as possible.
3) We do not know how long we need to go from the freeze to GA. We hope for
2 months but our last experience was 6 months. So delaying the release
could mean not releasing this year.
4) For people doing marketing it is really hard to promote a product when
you do not know when the release will come and what features might be there.
All those concerns are probably even made worse by the fact that we do not
have a clear visibility on where we are.
Should we clarify that part first by getting an idea of the status of the
different CEPs and other big pieces of work? From there we could agree on
some timeline for the freeze. We could then discuss how to make predictable
the time from freeze to GA.
Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jm...@apache.org> a écrit :
> (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 <be...@apache.org>
> *Sent:* Wednesday, March 1, 2023 5:59 AM
> *To:* dev@cassandra.apache.org <de...@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 <mc...@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
Posted by Josh McKenzie <jm...@apache.org>.
(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 <be...@apache.org>
> *Sent:* Wednesday, March 1, 2023 5:59 AM
> *To:* dev@cassandra.apache.org <de...@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 <mc...@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
Posted by German Eichberger via dev <de...@cassandra.apache.org>.
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 <be...@apache.org>
Sent: Wednesday, March 1, 2023 5:59 AM
To: dev@cassandra.apache.org <de...@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 <mc...@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: [DISCUSS] Next release date
Posted by Benedict <be...@apache.org>.
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 <mc...@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: [DISCUSS] Next release date
Posted by David Capwell <dc...@apple.com>.
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 <je...@gmail.com> 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 <he...@datastax.com> 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 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 of view just as we have worked hard to get some of these big features in earlier, it would not be completely wrong to allow some to finish their work in the days and weeks after the official cutoff date. It seems this is my answer to Mick's question 2a.
>>
>>
>> In contrast, I fear that if we postpone the branch date altogether, it will delay everything and we will just have this same discussion in September again.
>>
>>
>> For the remaining questions, I would also be interested to hear answers to questions #1 and #2.
>>
>> henrik
>>
>>
>>
>> On Wed, Mar 1, 2023 at 3:38 PM Mick Semb Wever <mck@apache.org <ma...@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?
>>
>>
>> --
>>
>> Henrik Ingo
>> c. +358 40 569 7354
>> w. www.datastax.com <http://www.datastax.com/>
>> <https://www.facebook.com/datastax> <https://twitter.com/datastax> <https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
Re: [DISCUSS] Next release date
Posted by "J. D. Jordan" <je...@gmail.com>.
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 <he...@datastax.com> 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 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 of view
> just as we have worked hard to get some of these big features in earlier, it
> would not be completely wrong to allow some to finish their work in the days
> and weeks after the official cutoff date. It seems this is my answer to
> Mick's question 2a.
>
>
>
>
>
>
>
> In contrast, I fear that if we postpone the branch date altogether, it will
> delay everything and we will just have this same discussion in September
> again.
>
>
>
>
>
>
>
> For the remaining questions, I would also be interested to hear answers to
> questions #1 and #2.
>
>
>
>
> henrik
>
>
>
>
>
>
>
>
>
>
> On Wed, Mar 1, 2023 at 3:38 PM Mick Semb Wever
> <[mck@apache.org](mailto:mck@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?
>
>
>
>
>
>
>
> \--
>
>
> 
>
> |
>
> Henrik Ingo
>
> c. +358 40 569 7354
>
> w. [www.datastax.com](http://www.datastax.com)
>
> [](https://www.facebook.com/datastax)
> [](https://twitter.com/datastax)
> [](https://www.linkedin.com/company/datastax/)
> [](https://github.com/datastax/)
>
>
>
> ---|---
Re: [DISCUSS] Next release date
Posted by Aleksey Yeshchenko <al...@apple.com>.
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 <he...@datastax.com> 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
Posted by Henrik Ingo <he...@datastax.com>.
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 of view
just as we have worked hard to get some of these big features in earlier,
it would not be completely wrong to allow some to finish their work in the
days and weeks after the official cutoff date. It seems this is my answer
to Mick's question 2a.
In contrast, I fear that if we postpone the branch date altogether, it will
delay everything and we will just have this same discussion in September
again.
For the remaining questions, I would also be interested to hear answers to
questions #1 and #2.
henrik
On Wed, Mar 1, 2023 at 3:38 PM Mick Semb Wever <mc...@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?
>
--
Henrik Ingo
c. +358 40 569 7354
w. www.datastax.com
<https://www.facebook.com/datastax> <https://twitter.com/datastax>
<https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
Re: [DISCUSS] Next release date
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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
Posted by "J. D. Jordan" <je...@gmail.com>.
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 <bl...@apache.org> 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