Re: [DISCUSS] Releases after 4.0

[Berenguer Blasi]

+1

On 30/3/21 3:43, David Capwell wrote:
> +1
>
>> On Mar 29, 2021, at 2:48 PM, Benedict Elliott Smith  
>> wrote:
>>
>> +1
>>
>> On 29/03/2021, 21:16, "Ben Bromhead"  wrote:
>>
>>+1 good sensible suggestion.
>>
>>On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova 
>> 
>>wrote:
>>
>>> I also like the latest suggestion, +1, thank you
>>>
>>> On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:
>>>
 +1

 On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
 wrote:

> +1 that deprecation schedule seems reasonable and a good thing to move
 to.
>> On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
 wrote:
>> The proposal sounds good to me too.
>>
>>> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> écrit :
 On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch <
>>> joe.e.ly...@gmail.com>
 wrote:
 I like the idea of the 3-year support cycles, but I think since
 3.0/3.11/4.0 took so long to stabilize to a point folks could
>>> upgrade
 to, we should reset the clock somewhat.
>>> I agree, the length of time to release 4.0 and the initialization
>>> of a
>>> new release cycle requires some special consideration for current
>>> releases.
>>>
 4.0: Fully supported until April 2023 and high severity bugs until
 April 2024 (2 year full, 1 year bugfix)
 3.11: Fully supported until April 2022 and high severity bugs until
 April 2023 (1 year full, 1 year bugfix).
 3.0: Supported for high severity correctness/performance bugs until
 April 2022 (1 year bugfix)
 2.2+2.1: EOL immediately.

 Then going forward we could have this nice pattern when we cut the
 yearly release:
 Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
 Y(n-1): Fully supported for 1 more year and supported for high
 severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
 Y(n-2): Supported for high severity correctness/bugs for 1 more
>>> year
 (1
>>> bugfix)
>>>
>>> This sounds excellent to me, +1.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>>
>>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
>>
>>-- 
>>
>>Ben Bromhead
>>
>>Instaclustr | www.instaclustr.com | @instaclustr
>> | +64 27 383 8975
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Dinesh Joshi]

+1

Dinesh

> On Mar 29, 2021, at 1:41 PM, Nate McCall  wrote:
> 
> +1
> 
> 
>> On Tue, Mar 30, 2021 at 2:06 AM Mick Semb Wever  wrote:
>> 
>> Proposing the test build of Cassandra 4.0-rc1 for release.
>> 
>> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
>> Git:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
>> Maven Artifacts:
>> 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
>> 
>> The vote will be open for 72 hours (longer if needed). Everyone who has
>> tested the build is invited to vote. Votes by PMC members are considered
>> binding. A vote passes if there are at least three binding +1s and no -1's.
>> 
>> Known issues with this release, that are planned to be fixed in 4.0-rc2,
>> are
>> - four files were missing copyright headers,
>> - LICENSE and NOTICE contain additional unneeded information,
>> - jar files under lib/ in the source artefact.
>> 
>> These issues are actively being worked on, along with our expectations that
>> the ASF makes the policy around them more explicit so it is clear exactly
>> what is required of us.
>> 
>> 
>> [1]: CHANGES.txt:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
>> [2]: NEWS.txt:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Download source release / binary files in source release

[Jeff Jirsa]

On Mon, Mar 29, 2021 at 3:45 PM Justin Mclean  wrote:

>
> It good to see you are taking action, but I think the situation is a
> little more seriously that you may realise, I suggest you look at what
> actions the board has taken in similar situations in the past. I'll update
> the board agenda item to reflect the current situation.
>
>
The thread linked earlier is worth reading for sure. Again,
https://lists.apache.org/thread.html/f8022be5a02c6f020aac635193e729a0f73376164cea7c38474c3dc0%401332948346%40%3Cgeneral.incubator.apache.org%3E

As an ASF member and a member of the Cassandra PMC, it's pretty clear what
Roy's position was in 2012.

My personal, emotional response is in line with what Rob Weir said in
2012:  "The issue should be lack of source code, not presence of binary
code."

If someone asked me what's included in a source release, without reading
ANY doc or policy, I'd expect there to be the complete, unabridged source
of the project, and enough context to build it. That's what Cassandra has
today. The extra binaries are just that - extra. They come with no burden.
They come with no obligation to use. They come with no penalty. The source
for which the PMC is responsible is published, and that feels far more
important to me than the absence of binary code that's trivial to remove.

Roy's response in the 2012 thread, though, is unambiguous: he strongly
believes, clearly with authority in 2012, that the presence of ANY binary
file violates the spirit of a source release. That feels quite extreme to
me, though this line is probably nuanced enough to inspire a book on trust:

"One cannot vote to approve a release containing a mix of source and binary
code because the binary is not open source and cannot be verified to be
safe for release (even if it was derived from open source)."

Based on this point, I personally won't vote to approve a future release
with binary packages, but I also strongly disagree with the assertion in
that same past thread that it's worth nuking a 10+year history of releases.
That's the type of action that would severely diminish trust in the
foundation.

We SHOULD look at what's required to rebuild PAST releases. We should also
admit that people are human and be reasonable along the way. Community over
code and all that.

Re: [DISCUSS] Releases after 4.0

[David Capwell]

+1

> On Mar 29, 2021, at 2:48 PM, Benedict Elliott Smith  
> wrote:
> 
> +1
> 
> On 29/03/2021, 21:16, "Ben Bromhead"  wrote:
> 
>+1 good sensible suggestion.
> 
>On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova 
>wrote:
> 
>> I also like the latest suggestion, +1, thank you
>> 
>> On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:
>> 
>>> +1
>>> 
>>> On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
>>> wrote:
>>> 
 +1 that deprecation schedule seems reasonable and a good thing to move
>>> to.
 
> On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
>>> wrote:
> 
> The proposal sounds good to me too.
> 
>> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
 écrit :
>> 
>>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch <
>> joe.e.ly...@gmail.com>
>>> wrote:
>>> I like the idea of the 3-year support cycles, but I think since
>>> 3.0/3.11/4.0 took so long to stabilize to a point folks could
>> upgrade
>>> to, we should reset the clock somewhat.
>> 
>> I agree, the length of time to release 4.0 and the initialization
>> of a
>> new release cycle requires some special consideration for current
>> releases.
>> 
>>> 4.0: Fully supported until April 2023 and high severity bugs until
>>> April 2024 (2 year full, 1 year bugfix)
>>> 3.11: Fully supported until April 2022 and high severity bugs until
>>> April 2023 (1 year full, 1 year bugfix).
>>> 3.0: Supported for high severity correctness/performance bugs until
>>> April 2022 (1 year bugfix)
>>> 2.2+2.1: EOL immediately.
>>> 
>>> Then going forward we could have this nice pattern when we cut the
>>> yearly release:
>>> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
>>> Y(n-1): Fully supported for 1 more year and supported for high
>>> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
>>> Y(n-2): Supported for high severity correctness/bugs for 1 more
>> year
>>> (1
>> bugfix)
>> 
>> This sounds excellent to me, +1.
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>>> 
>> 
> 
> 
>-- 
> 
>Ben Bromhead
> 
>Instaclustr | www.instaclustr.com | @instaclustr
> | +64 27 383 8975
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [Vote] Remove Windows support from 4.0+

[Paulo Motta]

Hi,

I wanted to call attention to the fact that while we removed Windows
support on CASSANDRA-16171 [1], we haven't added instructions on how to run
Cassandra on Windows with docker/WSL
for those users that potentially relied on Windows support.
(CASSANDRA-16173[2], CASSANDRA-15887[3]).

While we probably shouldn't block GA on this I think we should at least
mention in the installation guide[4] that native Windows support was
dropped on 4.0 for those that relied on this. This can be done
independently from the official artifacts since it's a separate repository.

To close the loop on this if there are no objections I will send an email
to the user list requesting volunteers to write the Windows instructions or
donate resources to provide official windows support if there's interest.

Cheers,

Paulo

[1] - https://issues.apache.org/jira/browse/CASSANDRA-16171
[2] - https://issues.apache.org/jira/browse/CASSANDRA-16173
[3] - https://issues.apache.org/jira/browse/CASSANDRA-15887
[4] -
https://cassandra.apache.org/doc/latest/getting_started/installing.html


Em seg., 10 de ago. de 2020 às 15:01, Joshua McKenzie 
escreveu:

> There's some significant performance differences between bare metal linux
> and WAL 2 as per phoronix' recent testing:
>
> https://www.phoronix.com/scan.php?page=article&item=windows10-may2020-wsl2&num=2
> ;
> I'd be wary of recommending it for *production* workloads but it certainly
> seems to work fine for dev.
>
> (context for those that don't know: I did the initial full windows support
> work back in 2014-2015) - my impression is that it's not a ton of work to
> keep things up to date / working with windows fwiw, but we as a community
> don't have anyone committed to maintaining support in 4.0 for Windows. It
> seems our general impression as a dev community is that there's minimal
> appetite for production usage of C* on Windows but we're lacking empirical
> evidence for or against.
>
> reached out with an explicit request for donation of support, making it
> > explicit that we will be removing support if none is forthcoming
>
> Seems like a reasonable enough approach to me.
>
>
>
> On Mon, Aug 10, 2020 at 1:02 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > I think it would seem a bit more legitimate to remove support without a
> > normal deprecation cycle if we've reached out with an explicit request
> for
> > donation of support, making it explicit that we will be removing support
> if
> > none is forthcoming.  But just my 2c; like most people on this list, even
> > discussing Windows support barely registers on my priority list.
> >
> > On 10/08/2020, 17:53, "Jordan West"  wrote:
> >
> > It wasn't directly regarding removing support but we did reach out to
> > cassandra-users@ for testing 4.0 on Windows and got no response:
> > https://www.mail-archive.com/user@cassandra.apache.org/msg60234.html
> >
> > Jordan
> >
> >
> > On Mon, Aug 10, 2020 at 4:16 AM Benedict Elliott Smith <
> > bened...@apache.org>
> > wrote:
> >
> > > Have we considered first asking the user list if there's anyone
> > willing to
> > > donate resources to maintain compatibility?
> > >
> > > I know I have in the (distant) past handled Jira filed by
> > (production)
> > > Windows users.  I don’t know how prevalent they are, but perhaps we
> > should
> > > offer them a chance to step up before cutting them off?  I
> understand
> > > nobody presently involved has the resources or inclination to
> > maintain
> > > them, but if the effort is low it is not infeasible that somebody
> > else
> > > might.
> > >
> > > On 10/08/2020, 12:11, "Aleksey Yeshchenko"
> > 
> > > wrote:
> > >
> > > +1
> > >
> > > > On 10 Aug 2020, at 04:14, Yuki Morishita 
> > wrote:
> > > >
> > > > As per the discussion(*), I propose to remove Windows support
> > from
> > > 4.0
> > > > release and onward.
> > > >
> > > > Windows scripts are not maintained and we lack windows test
> > > > environments. WIndows users can  use docker or cloud
> > environments to
> > > > set up Cassandra application development.
> > > >
> > > > If the vote pass, I will create the following tickets to
> > officially
> > > > remove Windows support from 4.0:
> > > >
> > > > - Remove Windows scripts and add notice to NEWS.txt
> > > > - Update "Getting Started" documents for Windows users (to
> > direct
> > > them
> > > > to use docker or cloud)
> > > >
> > > > Regards,
> > > > Yuki
> > > >
> > > > --
> > > > *:
> > >
> >
> https://mail-archives.apache.org/mod_mbox/cassandra-dev/202007.mbox/%3CCAGM0Up_3GoPucCP-U18L1akzBXS1eJoKbui997%3DajcCfKJQdng%40mail.gmail.com%3E
> > > >
> > > >
> > -
> > > > 

Re: Download source release / binary files in source release

[Benedict Elliott Smith]

> I think the situation is a little more seriously that you may realise, I 
> suggest you look at what actions the board has taken in similar situations in 
> the past

 

I thought you had already indicated the likely remedy: the removal of 
non-compliant releases?

 

I’m puzzled by your desire for immediate action. The enquiries you initiated 
are still ongoing. Surely, once they conclude, they will afford some time for 
the community to decide how to accommodate the ruling?

 

 

From: Justin Mclean 
Sent: Monday, March 29, 2021 11:45:29 PM
To: dev@cassandra.apache.org 
Subject: Re: Download source release / binary files in source release 

 

Hi,

> To the PMC: the next boarding meeting is on 21st April, so we have time to
> get this release out and probably more as well (hopefully with the fix
> for CASSANDRA-16391) before that date.

If I was a PMC member here, I would reconsider making that release without 
fixing this issue. I would also discuss on list how previous releases can be 
corrected and how much effort that might be. This is just a friendly suggestion.

> Would you mind switching hats here and also representing the project by
> including the following items:
>  - the project is actively working on addressing the fault,
>  - the project has taken this approach since incubation²,
>  - no one has mentioned it until now, and in the middle of a release vote
> are expecting an impromptu change,
>  - there is agreement, in the project and on legal³, that the ASF policy
> docs are not clear on the matter and needs to be improved,
>  - the project is very keen to see those docs improved asap so to be
> confident of changes they invest in.

It good to see you are taking action, but I think the situation is a little 
more seriously that you may realise, I suggest you look at what actions the 
board has taken in similar situations in the past. I'll update the board agenda 
item to reflect the current situation.

Thanks,
Justin

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Paulo Motta]

> I am planning to open some follow up discussions for those points in the
coming weeks.

Awesome, thanks for coordinating this!

> It is a valid point. Do you mind if I update the documentation when we
have
clarified the version names and that we have a more precise idea of when
4.0 GA will be released?

Sounds good to me!

>  What do you think?

+1 to Joey's addendum proposal to 3.0/3.11 end-of-support cycle.

> I wanted to suggest an addendum that a review of 4.0/3.x support be done
in
(say) April 2022 in case of delays with 5.x [and beyond]. Thoughts?

I think this is a valid point, but I don't think we need to prescribe this,
since we can always re-discuss end-of-support dates if there is a delay.
Perhaps we can add a short note to the support page that end-of-support
dates may be revised if there are changes to the release schedule.

Em seg., 29 de mar. de 2021 às 19:20, Erick Ramirez <
erick.rami...@datastax.com> escreveu:

> +1 excellent proposal. It makes it easier for the community to understand
> and plan ahead.
>
> I wanted to suggest an addendum that a review of 4.0/3.x support be done in
> (say) April 2022 in case of delays with 5.x [and beyond]. Thoughts?
>
> On Tue, 30 Mar 2021 at 01:41, Joseph Lynch  wrote:
>
> > I am slightly concerned about removing support for critical bug fixes
> > in 3.0 on a short time-frame (<1 year). I know of at least a few major
> > installations, including ours, who are just now able to finish
> > upgrades to 3.0 in production due to the number of correctness and
> > performance bugs introduced in that release which have only been
> > debugged and fixed in the past ~2 years.
> >
> > I like the idea of the 3-year support cycles, but I think since
> > 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
> > to, we should reset the clock somewhat. What about the following
> > assuming an April 2021 4.0 cut:
> >
> > 4.0: Fully supported until April 2023 and high severity bugs until
> > April 2024 (2 year full, 1 year bugfix)
> > 3.11: Fully supported until April 2022 and high severity bugs until
> > April 2023 (1 year full, 1 year bugfix).
> > 3.0: Supported for high severity correctness/performance bugs until
> > April 2022 (1 year bugfix)
> > 2.2+2.1: EOL immediately.
> >
> > Then going forward we could have this nice pattern when we cut the
> > yearly release:
> > Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> > Y(n-1): Fully supported for 1 more year and supported for high
> > severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> > Y(n-2): Supported for high severity correctness/bugs for 1 more year (1
> > bugfix)
> >
> > What do you think?
> > -Joey
> >
> > On Mon, Mar 29, 2021 at 9:39 AM Benjamin Lerer
> >  wrote:
> > >
> > > Thanks to everybody and sorry for not finalizing that email thread
> > sooner.
> > >
> > > For the release cadence the agreement is:* one release every year +
> > > periodic trunc snapshot*
> > > For the number of releases being supported the agreement is 3.  *Every
> > > incoming release should be supported for 3 years.*
> > >
> > > We did not reach a clear agreement on several points :
> > > * The naming of versions: semver versus another approach and the name
> of
> > > snapshot versions
> > > * How long will we support 3.11. Taking into account that it has been
> > > released 4 years ago does it make sense to support it for the next 3
> > years?
> > >
> > > I am planning to open some follow up discussions for those points in
> the
> > > coming weeks.
> > >
> > > When there is an agreement we should document the changes on the
> webpage
> > > > and also highlight it as part of the 4.0 release material as it's an
> > > > important change to the release cycle and LTS support.
> > > >
> > >
> > > It is a valid point. Do you mind if I update the documentation when we
> > have
> > > clarified the version names and that we have a more precise idea of
> when
> > > 4.0 GA will be released? That will allow us to make a clear message on
> > when
> > > to expect the next supported version.
> > >
> > > On Mon, Feb 8, 2021 at 10:05 PM Paulo Motta 
> > > wrote:
> > >
> > > > +1 to the yearly release cadence + periodic trunk snapshots + support
> > to 3
> > > > previous release branches.. I think this will give some nice
> > predictability
> > > > to the project.
> > > >
> > > > When there is an agreement we should document the changes on the
> > webpage
> > > > and also highlight it as part of the 4.0 release material as it's an
> > > > important change to the release cycle and LTS support.
> > > >
> > > > Em sex., 5 de fev. de 2021 às 18:08, Brandon Williams <
> > dri...@gmail.com>
> > > > escreveu:
> > > >
> > > > > Perhaps on my third try...  keep three branches total, including
> > 3.11:
> > > > > 3.11, 4, next. Support for 3.11 begins ending after next+1, is what
> > > > > I'm trying to convey.
> > > > >
> > > > > On Fri, Feb 5, 2021 at 2:58 PM Brandon Williams 
> > > > wrote:
> > > > > >
> > > > > > 

Re: Download source release / binary files in source release

[Justin Mclean]

Hi,

> To the PMC: the next boarding meeting is on 21st April, so we have time to
> get this release out and probably more as well (hopefully with the fix
> for CASSANDRA-16391) before that date.

If I was a PMC member here, I would reconsider making that release without 
fixing this issue. I would also discuss on list how previous releases can be 
corrected and how much effort that might be. This is just a friendly suggestion.

> Would you mind switching hats here and also representing the project by
> including the following items:
>  - the project is actively working on addressing the fault,
>  - the project has taken this approach since incubation²,
>  - no one has mentioned it until now, and in the middle of a release vote
> are expecting an impromptu change,
>  - there is agreement, in the project and on legal³, that the ASF policy
> docs are not clear on the matter and needs to be improved,
>  - the project is very keen to see those docs improved asap so to be
> confident of changes they invest in.

It good to see you are taking action, but I think the situation is a little 
more seriously that you may realise, I suggest you look at what actions the 
board has taken in similar situations in the past. I'll update the board agenda 
item to reflect the current situation.

Thanks,
Justin

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Erick Ramirez]

+1 excellent proposal. It makes it easier for the community to understand
and plan ahead.

I wanted to suggest an addendum that a review of 4.0/3.x support be done in
(say) April 2022 in case of delays with 5.x [and beyond]. Thoughts?

On Tue, 30 Mar 2021 at 01:41, Joseph Lynch  wrote:

> I am slightly concerned about removing support for critical bug fixes
> in 3.0 on a short time-frame (<1 year). I know of at least a few major
> installations, including ours, who are just now able to finish
> upgrades to 3.0 in production due to the number of correctness and
> performance bugs introduced in that release which have only been
> debugged and fixed in the past ~2 years.
>
> I like the idea of the 3-year support cycles, but I think since
> 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
> to, we should reset the clock somewhat. What about the following
> assuming an April 2021 4.0 cut:
>
> 4.0: Fully supported until April 2023 and high severity bugs until
> April 2024 (2 year full, 1 year bugfix)
> 3.11: Fully supported until April 2022 and high severity bugs until
> April 2023 (1 year full, 1 year bugfix).
> 3.0: Supported for high severity correctness/performance bugs until
> April 2022 (1 year bugfix)
> 2.2+2.1: EOL immediately.
>
> Then going forward we could have this nice pattern when we cut the
> yearly release:
> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> Y(n-1): Fully supported for 1 more year and supported for high
> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> Y(n-2): Supported for high severity correctness/bugs for 1 more year (1
> bugfix)
>
> What do you think?
> -Joey
>
> On Mon, Mar 29, 2021 at 9:39 AM Benjamin Lerer
>  wrote:
> >
> > Thanks to everybody and sorry for not finalizing that email thread
> sooner.
> >
> > For the release cadence the agreement is:* one release every year +
> > periodic trunc snapshot*
> > For the number of releases being supported the agreement is 3.  *Every
> > incoming release should be supported for 3 years.*
> >
> > We did not reach a clear agreement on several points :
> > * The naming of versions: semver versus another approach and the name of
> > snapshot versions
> > * How long will we support 3.11. Taking into account that it has been
> > released 4 years ago does it make sense to support it for the next 3
> years?
> >
> > I am planning to open some follow up discussions for those points in the
> > coming weeks.
> >
> > When there is an agreement we should document the changes on the webpage
> > > and also highlight it as part of the 4.0 release material as it's an
> > > important change to the release cycle and LTS support.
> > >
> >
> > It is a valid point. Do you mind if I update the documentation when we
> have
> > clarified the version names and that we have a more precise idea of when
> > 4.0 GA will be released? That will allow us to make a clear message on
> when
> > to expect the next supported version.
> >
> > On Mon, Feb 8, 2021 at 10:05 PM Paulo Motta 
> > wrote:
> >
> > > +1 to the yearly release cadence + periodic trunk snapshots + support
> to 3
> > > previous release branches.. I think this will give some nice
> predictability
> > > to the project.
> > >
> > > When there is an agreement we should document the changes on the
> webpage
> > > and also highlight it as part of the 4.0 release material as it's an
> > > important change to the release cycle and LTS support.
> > >
> > > Em sex., 5 de fev. de 2021 às 18:08, Brandon Williams <
> dri...@gmail.com>
> > > escreveu:
> > >
> > > > Perhaps on my third try...  keep three branches total, including
> 3.11:
> > > > 3.11, 4, next. Support for 3.11 begins ending after next+1, is what
> > > > I'm trying to convey.
> > > >
> > > > On Fri, Feb 5, 2021 at 2:58 PM Brandon Williams 
> > > wrote:
> > > > >
> > > > > Err, to be clear: keep 3.11 until we have 3 other branches.
> > > > >
> > > > > On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams 
> > > > wrote:
> > > > > >
> > > > > > I'm +1 on 3 branches, and thus ~3 years of support.  So in the
> > > > > > transition, would we aim to keep 3.11 until after 4.0 and a
> successor
> > > > > > are released?
> > > > > >
> > > > > > On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer
> > > > > >  wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Are we also trying to reach a consensus here that a release
> > > branch
> > > > should
> > > > > > > > be supported for ~3 years (i.e. that we are aiming to limit
> > > > ourselves to 3
> > > > > > > > release branches plus trunk)?
> > > > > > >
> > > > > > >
> > > > > > > 3 release branches make sense to me +1
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever <
> m...@apache.org>
> > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > > I believe that there is an appetite for the bleeding edge
> > > > snapshots where
> > > > > > > > > we do not guarantee stability and that the semver
> discussion is

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

+1

On 29/03/2021, 21:16, "Ben Bromhead"  wrote:

+1 good sensible suggestion.

On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova 
wrote:

> I also like the latest suggestion, +1, thank you
>
> On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:
>
> > +1
> >
> > On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
> > wrote:
> >
> > > +1 that deprecation schedule seems reasonable and a good thing to move
> > to.
> > >
> > > > On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
> > wrote:
> > > >
> > > > The proposal sounds good to me too.
> > > >
> > > >> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> > > écrit :
> > > >>
> > > >>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch <
> joe.e.ly...@gmail.com>
> > > >>> wrote:
> > > >>> I like the idea of the 3-year support cycles, but I think since
> > > >>> 3.0/3.11/4.0 took so long to stabilize to a point folks could
> upgrade
> > > >>> to, we should reset the clock somewhat.
> > > >>
> > > >> I agree, the length of time to release 4.0 and the initialization
> of a
> > > >> new release cycle requires some special consideration for current
> > > >> releases.
> > > >>
> > > >>> 4.0: Fully supported until April 2023 and high severity bugs until
> > > >>> April 2024 (2 year full, 1 year bugfix)
> > > >>> 3.11: Fully supported until April 2022 and high severity bugs 
until
> > > >>> April 2023 (1 year full, 1 year bugfix).
> > > >>> 3.0: Supported for high severity correctness/performance bugs 
until
> > > >>> April 2022 (1 year bugfix)
> > > >>> 2.2+2.1: EOL immediately.
> > > >>>
> > > >>> Then going forward we could have this nice pattern when we cut the
> > > >>> yearly release:
> > > >>> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> > > >>> Y(n-1): Fully supported for 1 more year and supported for high
> > > >>> severity correctness/perf bugs 1 year after that (1 full, 1 
bugfix)
> > > >>> Y(n-2): Supported for high severity correctness/bugs for 1 more
> year
> > (1
> > > >> bugfix)
> > > >>
> > > >> This sounds excellent to me, +1.
> > > >>
> > > >>
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>
> > > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Nate McCall]

+1


On Tue, Mar 30, 2021 at 2:06 AM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 4.0-rc1 for release.
>
> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> Known issues with this release, that are planned to be fixed in 4.0-rc2,
> are
>  - four files were missing copyright headers,
>  - LICENSE and NOTICE contain additional unneeded information,
>  - jar files under lib/ in the source artefact.
>
> These issues are actively being worked on, along with our expectations that
> the ASF makes the policy around them more explicit so it is clear exactly
> what is required of us.
>
>
> [1]: CHANGES.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> [2]: NEWS.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>

Re: [DISCUSS] Releases after 4.0

[Ben Bromhead]

+1 good sensible suggestion.

On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova 
wrote:

> I also like the latest suggestion, +1, thank you
>
> On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:
>
> > +1
> >
> > On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
> > wrote:
> >
> > > +1 that deprecation schedule seems reasonable and a good thing to move
> > to.
> > >
> > > > On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
> > wrote:
> > > >
> > > > The proposal sounds good to me too.
> > > >
> > > >> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> > > écrit :
> > > >>
> > > >>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch <
> joe.e.ly...@gmail.com>
> > > >>> wrote:
> > > >>> I like the idea of the 3-year support cycles, but I think since
> > > >>> 3.0/3.11/4.0 took so long to stabilize to a point folks could
> upgrade
> > > >>> to, we should reset the clock somewhat.
> > > >>
> > > >> I agree, the length of time to release 4.0 and the initialization
> of a
> > > >> new release cycle requires some special consideration for current
> > > >> releases.
> > > >>
> > > >>> 4.0: Fully supported until April 2023 and high severity bugs until
> > > >>> April 2024 (2 year full, 1 year bugfix)
> > > >>> 3.11: Fully supported until April 2022 and high severity bugs until
> > > >>> April 2023 (1 year full, 1 year bugfix).
> > > >>> 3.0: Supported for high severity correctness/performance bugs until
> > > >>> April 2022 (1 year bugfix)
> > > >>> 2.2+2.1: EOL immediately.
> > > >>>
> > > >>> Then going forward we could have this nice pattern when we cut the
> > > >>> yearly release:
> > > >>> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> > > >>> Y(n-1): Fully supported for 1 more year and supported for high
> > > >>> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> > > >>> Y(n-2): Supported for high severity correctness/bugs for 1 more
> year
> > (1
> > > >> bugfix)
> > > >>
> > > >> This sounds excellent to me, +1.
> > > >>
> > > >>
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>
> > > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975

Re: [DISCUSS] Releases after 4.0

[Ekaterina Dimitrova]

I also like the latest suggestion, +1, thank you

On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:

> +1
>
> On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
> wrote:
>
> > +1 that deprecation schedule seems reasonable and a good thing to move
> to.
> >
> > > On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
> wrote:
> > >
> > > The proposal sounds good to me too.
> > >
> > >> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> > écrit :
> > >>
> > >>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch 
> > >>> wrote:
> > >>> I like the idea of the 3-year support cycles, but I think since
> > >>> 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
> > >>> to, we should reset the clock somewhat.
> > >>
> > >> I agree, the length of time to release 4.0 and the initialization of a
> > >> new release cycle requires some special consideration for current
> > >> releases.
> > >>
> > >>> 4.0: Fully supported until April 2023 and high severity bugs until
> > >>> April 2024 (2 year full, 1 year bugfix)
> > >>> 3.11: Fully supported until April 2022 and high severity bugs until
> > >>> April 2023 (1 year full, 1 year bugfix).
> > >>> 3.0: Supported for high severity correctness/performance bugs until
> > >>> April 2022 (1 year bugfix)
> > >>> 2.2+2.1: EOL immediately.
> > >>>
> > >>> Then going forward we could have this nice pattern when we cut the
> > >>> yearly release:
> > >>> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> > >>> Y(n-1): Fully supported for 1 more year and supported for high
> > >>> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> > >>> Y(n-2): Supported for high severity correctness/bugs for 1 more year
> (1
> > >> bugfix)
> > >>
> > >> This sounds excellent to me, +1.
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Yifan Cai]

+1 nb

On Mon, Mar 29, 2021 at 9:33 AM Aleksey Yeshchenko
 wrote:

> +1
>
> > On 29 Mar 2021, at 14:05, Mick Semb Wever  wrote:
> >
> > Proposing the test build of Cassandra 4.0-rc1 for release.
> >
> > sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote passes if there are at least three binding +1s and no
> -1's.
> >
> > Known issues with this release, that are planned to be fixed in 4.0-rc2,
> are
> > - four files were missing copyright headers,
> > - LICENSE and NOTICE contain additional unneeded information,
> > - jar files under lib/ in the source artefact.
> >
> > These issues are actively being worked on, along with our expectations
> that
> > the ASF makes the policy around them more explicit so it is clear exactly
> > what is required of us.
> >
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Releases after 4.0

[Yifan Cai]

+1

On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
wrote:

> +1 that deprecation schedule seems reasonable and a good thing to move to.
>
> > On Mar 29, 2021, at 10:23 AM, Benjamin Lerer  wrote:
> >
> > The proposal sounds good to me too.
> >
> >> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> écrit :
> >>
> >>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch 
> >>> wrote:
> >>> I like the idea of the 3-year support cycles, but I think since
> >>> 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
> >>> to, we should reset the clock somewhat.
> >>
> >> I agree, the length of time to release 4.0 and the initialization of a
> >> new release cycle requires some special consideration for current
> >> releases.
> >>
> >>> 4.0: Fully supported until April 2023 and high severity bugs until
> >>> April 2024 (2 year full, 1 year bugfix)
> >>> 3.11: Fully supported until April 2022 and high severity bugs until
> >>> April 2023 (1 year full, 1 year bugfix).
> >>> 3.0: Supported for high severity correctness/performance bugs until
> >>> April 2022 (1 year bugfix)
> >>> 2.2+2.1: EOL immediately.
> >>>
> >>> Then going forward we could have this nice pattern when we cut the
> >>> yearly release:
> >>> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> >>> Y(n-1): Fully supported for 1 more year and supported for high
> >>> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> >>> Y(n-2): Supported for high severity correctness/bugs for 1 more year (1
> >> bugfix)
> >>
> >> This sounds excellent to me, +1.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Aleksey Yeshchenko]

+1

> On 29 Mar 2021, at 14:05, Mick Semb Wever  wrote:
> 
> Proposing the test build of Cassandra 4.0-rc1 for release.
> 
> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> Known issues with this release, that are planned to be fixed in 4.0-rc2, are
> - four files were missing copyright headers,
> - LICENSE and NOTICE contain additional unneeded information,
> - jar files under lib/ in the source artefact.
> 
> These issues are actively being worked on, along with our expectations that
> the ASF makes the policy around them more explicit so it is clear exactly
> what is required of us.
> 
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[J. D. Jordan]

+1 that deprecation schedule seems reasonable and a good thing to move to.

> On Mar 29, 2021, at 10:23 AM, Benjamin Lerer  wrote:
> 
> The proposal sounds good to me too.
> 
>> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a écrit :
>> 
>>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch 
>>> wrote:
>>> I like the idea of the 3-year support cycles, but I think since
>>> 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
>>> to, we should reset the clock somewhat.
>> 
>> I agree, the length of time to release 4.0 and the initialization of a
>> new release cycle requires some special consideration for current
>> releases.
>> 
>>> 4.0: Fully supported until April 2023 and high severity bugs until
>>> April 2024 (2 year full, 1 year bugfix)
>>> 3.11: Fully supported until April 2022 and high severity bugs until
>>> April 2023 (1 year full, 1 year bugfix).
>>> 3.0: Supported for high severity correctness/performance bugs until
>>> April 2022 (1 year bugfix)
>>> 2.2+2.1: EOL immediately.
>>> 
>>> Then going forward we could have this nice pattern when we cut the
>>> yearly release:
>>> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
>>> Y(n-1): Fully supported for 1 more year and supported for high
>>> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
>>> Y(n-2): Supported for high severity correctness/bugs for 1 more year (1
>> bugfix)
>> 
>> This sounds excellent to me, +1.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

The proposal sounds good to me too.

Le lun. 29 mars 2021 à 16:48, Brandon Williams  a écrit :

> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch 
> wrote:
> > I like the idea of the 3-year support cycles, but I think since
> > 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
> > to, we should reset the clock somewhat.
>
> I agree, the length of time to release 4.0 and the initialization of a
> new release cycle requires some special consideration for current
> releases.
>
> > 4.0: Fully supported until April 2023 and high severity bugs until
> > April 2024 (2 year full, 1 year bugfix)
> > 3.11: Fully supported until April 2022 and high severity bugs until
> > April 2023 (1 year full, 1 year bugfix).
> > 3.0: Supported for high severity correctness/performance bugs until
> > April 2022 (1 year bugfix)
> > 2.2+2.1: EOL immediately.
> >
> > Then going forward we could have this nice pattern when we cut the
> > yearly release:
> > Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> > Y(n-1): Fully supported for 1 more year and supported for high
> > severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> > Y(n-2): Supported for high severity correctness/bugs for 1 more year (1
> bugfix)
>
> This sounds excellent to me, +1.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Releases after 4.0

[Brandon Williams]

On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch  wrote:
> I like the idea of the 3-year support cycles, but I think since
> 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
> to, we should reset the clock somewhat.

I agree, the length of time to release 4.0 and the initialization of a
new release cycle requires some special consideration for current
releases.

> 4.0: Fully supported until April 2023 and high severity bugs until
> April 2024 (2 year full, 1 year bugfix)
> 3.11: Fully supported until April 2022 and high severity bugs until
> April 2023 (1 year full, 1 year bugfix).
> 3.0: Supported for high severity correctness/performance bugs until
> April 2022 (1 year bugfix)
> 2.2+2.1: EOL immediately.
>
> Then going forward we could have this nice pattern when we cut the
> yearly release:
> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> Y(n-1): Fully supported for 1 more year and supported for high
> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> Y(n-2): Supported for high severity correctness/bugs for 1 more year (1 
> bugfix)

This sounds excellent to me, +1.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Joseph Lynch]

I am slightly concerned about removing support for critical bug fixes
in 3.0 on a short time-frame (<1 year). I know of at least a few major
installations, including ours, who are just now able to finish
upgrades to 3.0 in production due to the number of correctness and
performance bugs introduced in that release which have only been
debugged and fixed in the past ~2 years.

I like the idea of the 3-year support cycles, but I think since
3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
to, we should reset the clock somewhat. What about the following
assuming an April 2021 4.0 cut:

4.0: Fully supported until April 2023 and high severity bugs until
April 2024 (2 year full, 1 year bugfix)
3.11: Fully supported until April 2022 and high severity bugs until
April 2023 (1 year full, 1 year bugfix).
3.0: Supported for high severity correctness/performance bugs until
April 2022 (1 year bugfix)
2.2+2.1: EOL immediately.

Then going forward we could have this nice pattern when we cut the
yearly release:
Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
Y(n-1): Fully supported for 1 more year and supported for high
severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
Y(n-2): Supported for high severity correctness/bugs for 1 more year (1 bugfix)

What do you think?
-Joey

On Mon, Mar 29, 2021 at 9:39 AM Benjamin Lerer
 wrote:
>
> Thanks to everybody and sorry for not finalizing that email thread sooner.
>
> For the release cadence the agreement is:* one release every year +
> periodic trunc snapshot*
> For the number of releases being supported the agreement is 3.  *Every
> incoming release should be supported for 3 years.*
>
> We did not reach a clear agreement on several points :
> * The naming of versions: semver versus another approach and the name of
> snapshot versions
> * How long will we support 3.11. Taking into account that it has been
> released 4 years ago does it make sense to support it for the next 3 years?
>
> I am planning to open some follow up discussions for those points in the
> coming weeks.
>
> When there is an agreement we should document the changes on the webpage
> > and also highlight it as part of the 4.0 release material as it's an
> > important change to the release cycle and LTS support.
> >
>
> It is a valid point. Do you mind if I update the documentation when we have
> clarified the version names and that we have a more precise idea of when
> 4.0 GA will be released? That will allow us to make a clear message on when
> to expect the next supported version.
>
> On Mon, Feb 8, 2021 at 10:05 PM Paulo Motta 
> wrote:
>
> > +1 to the yearly release cadence + periodic trunk snapshots + support to 3
> > previous release branches.. I think this will give some nice predictability
> > to the project.
> >
> > When there is an agreement we should document the changes on the webpage
> > and also highlight it as part of the 4.0 release material as it's an
> > important change to the release cycle and LTS support.
> >
> > Em sex., 5 de fev. de 2021 às 18:08, Brandon Williams 
> > escreveu:
> >
> > > Perhaps on my third try...  keep three branches total, including 3.11:
> > > 3.11, 4, next. Support for 3.11 begins ending after next+1, is what
> > > I'm trying to convey.
> > >
> > > On Fri, Feb 5, 2021 at 2:58 PM Brandon Williams 
> > wrote:
> > > >
> > > > Err, to be clear: keep 3.11 until we have 3 other branches.
> > > >
> > > > On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams 
> > > wrote:
> > > > >
> > > > > I'm +1 on 3 branches, and thus ~3 years of support.  So in the
> > > > > transition, would we aim to keep 3.11 until after 4.0 and a successor
> > > > > are released?
> > > > >
> > > > > On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer
> > > > >  wrote:
> > > > > >
> > > > > > >
> > > > > > > Are we also trying to reach a consensus here that a release
> > branch
> > > should
> > > > > > > be supported for ~3 years (i.e. that we are aiming to limit
> > > ourselves to 3
> > > > > > > release branches plus trunk)?
> > > > > >
> > > > > >
> > > > > > 3 release branches make sense to me +1
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever 
> > > wrote:
> > > > > >
> > > > > > >
> > > > > > > > I believe that there is an appetite for the bleeding edge
> > > snapshots where
> > > > > > > > we do not guarantee stability and that the semver discussion is
> > > not
> > > > > > > > finished yet but I would like us to let those discussions go
> > for
> > > some
> > > > > > > > follow up threads.
> > > > > > > > My goal with this thread was to reach an agreement on a release
> > > cadence
> > > > > > > for
> > > > > > > > the version we will officially support after 4.0.
> > > > > > > >
> > > > > > > > My impression is that most people agree with *one release every
> > > year* so
> > > > > > > I
> > > > > > > > would like to propose it as our future release cadence.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > 

Re: [DISCUSSION] When should we branch 4.0 and unfreeze trunk?

[Benjamin Lerer]

 Thanks for your answers.

I agree to this proposal but I'm suggesting we close and codify the release
> cadence discussion from [1] before we lift the freeze, and maybe kick off
> the roadmap discussion but we probably shouldn't block the unfreeze on
> this.
>

Sorry, for not closing the release discussion sooner. There are still some
points to discuss regarding the release but I believe we have at least some
agreements on the cadence.

Regarding the roadmap discussion :

My proposal would be to get 4.0-RC out of the door and let a couple of
> weeks for people to think about the next release. Then we can trigger a
> discussion for everybody on what they are willing to focus on first.
>

Starting the discussion before RC sounded a bit premature and we needed to
let people a bit of time to clarify their plans. I am willing to fire that
discussion next week if everybody feels ready.

Looking back at the thread from [1] I saw that while we reached an
> agreement on the release cadence, we haven't discussed how we plan to
> ensure the quality of the releases moving forward, so we should also kick
> off this discussion but also don't need to block branching on this.


My understanding was that we should continue improving our testing coverage
and expand our use of Harry and cassandra-diff. The goal being to have a
green CI that we can  trust and be able in theory to cut a snapshot release
at any time. Nevertheless, I agree with you that it makes sense to have a
discussion on that subject too.

Regarding the concerns toward lifting the freeze. I believe that the main
concern was linked to the development efforts for 4.0. By creating a 4.0
branch we were taking the risk to have some resources that were focusing on
4.0 starting to shift their focus to other tasks or wasting time merging to
trunk.
Currently, we only have 16 tickets left for 4.0 GA and most of them are
actively worked on. By consequence, I believe that the risk of branching is
relatively small.
Does Anybody feel differently?

Le sam. 27 mars 2021 à 01:06, Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> a écrit :

> (mostly reiterating) +1 to branching and unfreezing trunk, and to codifying
> the release cadence.
> Excited about the 4.0 rc! and looking forward to the roadmap discussion!!
>
> On Thu, Mar 25, 2021 at 8:18 AM Paulo Motta 
> wrote:
>
> > > My thinking was talking about when to lift the freeze was moot if we
> > hadn't branched, and the agreed upon release lifecycle is pretty clear
> that
> > we don't branch until GA. Am I misunderstanding the relationship there?
> >
> > The proposal of this thread is to branch and lift the freeze before GA.
> >
> > I agree to this proposal but I'm suggesting we close and codify the
> release
> > cadence discussion from [1] before we lift the freeze, and maybe kick off
> > the roadmap discussion but we probably shouldn't block the unfreeze on
> > this.
> >
> > Looking back at the thread from [1] I saw that while we reached an
> > agreement on the release cadence, we haven't discussed how we plan to
> > ensure the quality of the releases moving forward, so we should also kick
> > off this discussion but also don't need to block branching on this.
> >
> > [1] -
> >
> >
> http://mail-archives.apache.org/mod_mbox/cassandra-dev/202101.mbox/%3ccabxe4tqrft9yn9tscd0jcs4qxe4vfeezqqtkbcw16d+3rgg...@mail.gmail.com%3e
> >
> >
> > Em qui., 25 de mar. de 2021 às 12:00, Joshua McKenzie <
> > jmcken...@apache.org>
> > escreveu:
> >
> > > >
> > > > be very practical and codify our existing agreements
> > > > discussed on the mentioned threads before lifting the freeze
> > >
> > > Ah. My thinking was talking about when to lift the freeze was moot if
> we
> > > hadn't branched, and the agreed upon release lifecycle is pretty clear
> > that
> > > we don't branch until GA. Am I misunderstanding the relationship there?
> > >
> > > On Thu, Mar 25, 2021 at 10:56 AM Paulo Motta  >
> > > wrote:
> > >
> > > > > That said, I think freezing feature contribution and not branching
> > > until
> > > > GA like we've newly done with 4.0 is bad for the health of the
> project
> > > >
> > > > +1. I think the freeze and branching until GA was atypical and unique
> > to
> > > > 4.0 and won't be repeated in the upcoming releases. I agree with
> > > Sumanth's
> > > > proposal on the release doc that branching should not be tied to a
> > > specific
> > > > release phase but decided independently by the community during the
> > > release
> > > > process (as it's being done now).
> > > >
> > > > > I think we should probably discuss the release process separately
> and
> > > > revise our agreements and process based on learnings from this
> release.
> > > >
> > > > Just to clarify: I'm not proposing we make a lengthy revision of the
> > > > release process, but be very practical and codify our existing
> > agreements
> > > > discussed on the mentioned threads before lifting the freeze and
> > discuss
> > > > any remaining concerns (just to en

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Andrés de la Peña]

+1 (non-binding)


On Mon, 29 Mar 2021 at 14:50, Brandon Williams  wrote:

> +1
>
> On Mon, Mar 29, 2021 at 8:05 AM Mick Semb Wever  wrote:
> >
> > Proposing the test build of Cassandra 4.0-rc1 for release.
> >
> > sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote passes if there are at least three binding +1s and no
> -1's.
> >
> > Known issues with this release, that are planned to be fixed in 4.0-rc2,
> are
> >  - four files were missing copyright headers,
> >  - LICENSE and NOTICE contain additional unneeded information,
> >  - jar files under lib/ in the source artefact.
> >
> > These issues are actively being worked on, along with our expectations
> that
> > the ASF makes the policy around them more explicit so it is clear exactly
> > what is required of us.
> >
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Berenguer Blasi]

+1

On 29/3/21 15:50, Brandon Williams wrote:
> +1
>
> On Mon, Mar 29, 2021 at 8:05 AM Mick Semb Wever  wrote:
>> Proposing the test build of Cassandra 4.0-rc1 for release.
>>
>> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
>>
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
>>
>> The vote will be open for 72 hours (longer if needed). Everyone who has
>> tested the build is invited to vote. Votes by PMC members are considered
>> binding. A vote passes if there are at least three binding +1s and no -1's.
>>
>> Known issues with this release, that are planned to be fixed in 4.0-rc2, are
>>  - four files were missing copyright headers,
>>  - LICENSE and NOTICE contain additional unneeded information,
>>  - jar files under lib/ in the source artefact.
>>
>> These issues are actively being worked on, along with our expectations that
>> the ASF makes the policy around them more explicit so it is clear exactly
>> what is required of us.
>>
>>
>> [1]: CHANGES.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> .

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Brandon Williams]

+1

On Mon, Mar 29, 2021 at 8:05 AM Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra 4.0-rc1 for release.
>
> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> Known issues with this release, that are planned to be fixed in 4.0-rc2, are
>  - four files were missing copyright headers,
>  - LICENSE and NOTICE contain additional unneeded information,
>  - jar files under lib/ in the source artefact.
>
> These issues are actively being worked on, along with our expectations that
> the ASF makes the policy around them more explicit so it is clear exactly
> what is required of us.
>
>
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Ekaterina Dimitrova]

+1 and thanks everyone for all the hard work

Checked:
- gpg signatures
- sha checksums
- binary convenience artifact runs
- src convenience artifacts builds with one command, and runs
- deb and rpm install and run

On Mon, 29 Mar 2021 at 9:39, Jonathan Ellis  wrote:

> +1
>
> On Mon, Mar 29, 2021 at 8:06 AM Mick Semb Wever  wrote:
>
> > Proposing the test build of Cassandra 4.0-rc1 for release.
> >
> > sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> > Git:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> > Maven Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote passes if there are at least three binding +1s and no
> -1's.
> >
> > Known issues with this release, that are planned to be fixed in 4.0-rc2,
> > are
> >  - four files were missing copyright headers,
> >  - LICENSE and NOTICE contain additional unneeded information,
> >  - jar files under lib/ in the source artefact.
> >
> > These issues are actively being worked on, along with our expectations
> that
> > the ASF makes the policy around them more explicit so it is clear exactly
> > what is required of us.
> >
> >
> > [1]: CHANGES.txt:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> > [2]: NEWS.txt:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
> >
>
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

Thanks to everybody and sorry for not finalizing that email thread sooner.

For the release cadence the agreement is:* one release every year +
periodic trunc snapshot*
For the number of releases being supported the agreement is 3.  *Every
incoming release should be supported for 3 years.*

We did not reach a clear agreement on several points :
* The naming of versions: semver versus another approach and the name of
snapshot versions
* How long will we support 3.11. Taking into account that it has been
released 4 years ago does it make sense to support it for the next 3 years?

I am planning to open some follow up discussions for those points in the
coming weeks.

When there is an agreement we should document the changes on the webpage
> and also highlight it as part of the 4.0 release material as it's an
> important change to the release cycle and LTS support.
>

It is a valid point. Do you mind if I update the documentation when we have
clarified the version names and that we have a more precise idea of when
4.0 GA will be released? That will allow us to make a clear message on when
to expect the next supported version.

On Mon, Feb 8, 2021 at 10:05 PM Paulo Motta 
wrote:

> +1 to the yearly release cadence + periodic trunk snapshots + support to 3
> previous release branches.. I think this will give some nice predictability
> to the project.
>
> When there is an agreement we should document the changes on the webpage
> and also highlight it as part of the 4.0 release material as it's an
> important change to the release cycle and LTS support.
>
> Em sex., 5 de fev. de 2021 às 18:08, Brandon Williams 
> escreveu:
>
> > Perhaps on my third try...  keep three branches total, including 3.11:
> > 3.11, 4, next. Support for 3.11 begins ending after next+1, is what
> > I'm trying to convey.
> >
> > On Fri, Feb 5, 2021 at 2:58 PM Brandon Williams 
> wrote:
> > >
> > > Err, to be clear: keep 3.11 until we have 3 other branches.
> > >
> > > On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams 
> > wrote:
> > > >
> > > > I'm +1 on 3 branches, and thus ~3 years of support.  So in the
> > > > transition, would we aim to keep 3.11 until after 4.0 and a successor
> > > > are released?
> > > >
> > > > On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer
> > > >  wrote:
> > > > >
> > > > > >
> > > > > > Are we also trying to reach a consensus here that a release
> branch
> > should
> > > > > > be supported for ~3 years (i.e. that we are aiming to limit
> > ourselves to 3
> > > > > > release branches plus trunk)?
> > > > >
> > > > >
> > > > > 3 release branches make sense to me +1
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever 
> > wrote:
> > > > >
> > > > > >
> > > > > > > I believe that there is an appetite for the bleeding edge
> > snapshots where
> > > > > > > we do not guarantee stability and that the semver discussion is
> > not
> > > > > > > finished yet but I would like us to let those discussions go
> for
> > some
> > > > > > > follow up threads.
> > > > > > > My goal with this thread was to reach an agreement on a release
> > cadence
> > > > > > for
> > > > > > > the version we will officially support after 4.0.
> > > > > > >
> > > > > > > My impression is that most people agree with *one release every
> > year* so
> > > > > > I
> > > > > > > would like to propose it as our future release cadence.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > +1 to branching off one release branch a year.
> > > > > >
> > > > > > Are we also trying to reach a consensus here that a release
> branch
> > should
> > > > > > be supported for ~3 years (i.e. that we are aiming to limit
> > ourselves to 3
> > > > > > release branches plus trunk)?
> > > > > >
> > > > > > +1 to flexible dates.
> > > > > >
> > > > > > +1 to non-GA non-branched releases along the way.
> > > > > >
> > > > > >
> > > > > > Jeremiah, I have nothing to add to your post. I think you did a
> > fantastic
> > > > > > job of combining how semver would work in combination Benedict's
> > focus on
> > > > > > cadence and reducing the community burden. It also helped
> > highlight the
> > > > > > different discussions to be had, that should be had separately.
> > Thanks
> > > > > > Benjamin for bringing it back to what was your original questions
> > (sorry
> > > > > > for the derail):
> > > > > >
> > > > > > > 1) What release cadence do we want to use for major/minor
> > versions?
> > > > > > > 2) How do we plan to ensure the quality of the releases?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > >
> > > > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional c

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Jonathan Ellis]

+1

On Mon, Mar 29, 2021 at 8:06 AM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 4.0-rc1 for release.
>
> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> Known issues with this release, that are planned to be fixed in 4.0-rc2,
> are
>  - four files were missing copyright headers,
>  - LICENSE and NOTICE contain additional unneeded information,
>  - jar files under lib/ in the source artefact.
>
> These issues are actively being worked on, along with our expectations that
> the ASF makes the policy around them more explicit so it is clear exactly
> what is required of us.
>
>
> [1]: CHANGES.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> [2]: NEWS.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>


-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Mick Semb Wever]

>
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote passes if there are at least three binding +1s and no
> -1's.
>


+1

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Benjamin Lerer]

+1

Le lun. 29 mars 2021 à 15:06, Mick Semb Wever  a écrit :

> Proposing the test build of Cassandra 4.0-rc1 for release.
>
> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> Known issues with this release, that are planned to be fixed in 4.0-rc2,
> are
>  - four files were missing copyright headers,
>  - LICENSE and NOTICE contain additional unneeded information,
>  - jar files under lib/ in the source artefact.
>
> These issues are actively being worked on, along with our expectations that
> the ASF makes the policy around them more explicit so it is clear exactly
> what is required of us.
>
>
> [1]: CHANGES.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> [2]: NEWS.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>

[VOTE] Release Apache Cassandra 4.0-rc1

[Mick Semb Wever]

Proposing the test build of Cassandra 4.0-rc1 for release.

sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/

The vote will be open for 72 hours (longer if needed). Everyone who has
tested the build is invited to vote. Votes by PMC members are considered
binding. A vote passes if there are at least three binding +1s and no -1's.

Known issues with this release, that are planned to be fixed in 4.0-rc2, are
 - four files were missing copyright headers,
 - LICENSE and NOTICE contain additional unneeded information,
 - jar files under lib/ in the source artefact.

These issues are actively being worked on, along with our expectations that
the ASF makes the policy around them more explicit so it is clear exactly
what is required of us.


[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative

Re: Download source release / binary files in source release

[Mick Semb Wever]

>
> I've also added a discussion item to the next board meeting.
>


Thanks.

To the PMC: the next boarding meeting is on 21st April, so we have time to
get this release out and probably more as well (hopefully with the fix
for CASSANDRA-16391) before that date.

To Justin: the board agenda item¹ as it is currently raised does not
represent our position or our request.

The issue we asked you to escale was an improvement to the docs to help us
move forward, quickly and with confidence.

Would you mind switching hats here and also representing the project by
including the following items:
 - the project is actively working on addressing the fault,
 - the project has taken this approach since incubation²,
 - no one has mentioned it until now, and in the middle of a release vote
are expecting an impromptu change,
 - there is agreement, in the project and on legal³, that the ASF policy
docs are not clear on the matter and needs to be improved,
 - the project is very keen to see those docs improved asap so to be
confident of changes they invest in.

I am more than happy to go in and edit the '8A Discuss action on Cassandra
releases', if that saves you time?

regards,
Mick


[1]
https://whimsy.apache.org/board/agenda/2021-04-21/Discuss-action-on-Cassandra-releases
[2] https://archive.apache.org/dist/cassandra/0.3.0/
[3]
https://lists.apache.org/thread.html/rd1aabe5052b5bedf3eceebd331f878b92a8ade6d4ca170f845d5db37%40%3Clegal-discuss.apache.org%3E