Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread Benedict Elliott Smith 
Indeed, sorry

+1; we may need to tweak it going forward, but it's a great staring (or midway) 
point


On 08/10/2019, 22:59, "Sankalp Kohli"  wrote:

Can we please stick to the vote here. We can always change the 
documentation as it will evolve over time. 


> On Oct 8, 2019, at 2:57 PM, Joshua McKenzie  wrote:
> 
> It probably warrants a separate discussion about how we version.
> 
> Also, robust +1 to what you said here bes and haddad  ;)
> 
>> On Tue, Oct 8, 2019 at 5:31 PM Jon Haddad  wrote:
>> 
>> This has definitely been a confusing topic in the past, I completely 
agree
>> Benedict.  Glad you brought this up.
>> 
>> I'm 100% on board with 5.0 after 4.0.
>> 
>> On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith 
>> 
>> wrote:
>> 
>>> As a brief side-step on the topic only of versioning (which no doubt 
will
>>> cause enough consternation), I personally endorse streamlining it.  We
>> have
>>> not had a consistently meaningful convention on this, at any point, and
>> we
>>> made it even worse in the 3.x line.  There's no real difference between
>>> 1.2->2.0, 2.0->2.1, or 3.0->3.11 and 3.11->4.0; let's admit this and go
>>> straight to 5.0 for our next feature release, with 4.1 our first patch
>>> release of the 4.x line.
>>> 
>>> 
 On 08/10/2019, 21:36, "Scott Andreas"  wrote:
>>> 
>>>Re: "How can we decide that *all* new features are suppose to go into
>>> trunk only, if we don’t even have an idea about the upcoming release
>>> schedule?"
>>> 
>>>This is a great question. My understanding of the intent of the
>>> document is that new features are generally expected to land in trunk,
>> with
>>> an exception process defined for feature backports. I think that's a
>>> reasonable expectation to start with. But I also agree with you that 
it's
>>> important we evolve a way to discuss and agree up on release scope - 
this
>>> was the focus of my slides at NGCC. I would love to discuss this on a
>>> separate thread.
>>> 
>>>Re: “Bug fix releases have associated new minor version.”
>>>"Patchlevel version" might be more in keeping with our current
>>> convention.
>>> 
>>>Re: "We should give users a way to plan, by having EOL dates"
>>>Incorporating EOL dates into our release management / planning is a
>>> great idea.
>>> 
>>>Would you be willing to rephrase your comments in the form of
>> proposed
>>> edits to the document?
>>> 
>>>– Scott
>>> 
>>>
>>>From: Stefan Podkowinski 
>>>Sent: Tuesday, October 8, 2019 1:22 PM
>>>To: dev@cassandra.apache.org
>>>Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
>>> 
>>> From the document:
>>> 
>>>General Availability (GA): “A new branch is created for the release
>>> with
>>>the new major version, limiting any new feature addition to the new
>>>release branch, with new feature development will continue to happen
>>>only on trunk.”
>>>Maintenance: “Missing features from newer generation releases are
>>>back-ported on per - PMC vote basis.”
>>> 
>>>We had a feature freeze before 4.0, which showed that people have
>>>different views on what actually qualifies as a feature. It doesn’t
>>> work
>>>without defining “feature” in more detail. Although I’d rather avoid
>> to
>>>have this in the document at all, since I don’t think this is getting
>>> us
>>>anywhere, without having a clearer picture on the bigger context in
>>>which release are going to happen in the future, starting with
>> release
>>>cadence and support periods. How can we decide that *all* new
>> features
>>>are suppose to go into trunk only, if we don’t even have an idea
>> about
>>>the upcoming release schedule?
>>> 
>>>“Bug fix releases have associated new minor version.”
>>> 
>>>So the next bug fix version will be 4.1? There will be no minor
>> feature
>>>releases like we did with 3.x.0/2.x.0?
>>> 
>>>Deprecated:
>>>"Through a dev community voting process, EOL date is determined for
>>> this
>>>release.”
>>>“Users actively encouraged to move away from the offering.”
>>> 
>>>We should give users a way to plan, by having EOL dates that may be
>>>months or years ahead in the future. We did this with 3.0 and 2.x,
>>> which
>>>would be all “deprecated” a long time ago with the new proposal.
>>> 
>>>Deprecated: “Only security vulnerabilities and production-impacting
>>> bugs
>>>without workarounds are addressed.”
>>> 
>>>Although devs will

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread Sankalp Kohli 
Can we please stick to the vote here. We can always change the documentation as 
it will evolve over time. 


> On Oct 8, 2019, at 2:57 PM, Joshua McKenzie  wrote:
> 
> It probably warrants a separate discussion about how we version.
> 
> Also, robust +1 to what you said here bes and haddad  ;)
> 
>> On Tue, Oct 8, 2019 at 5:31 PM Jon Haddad  wrote:
>> 
>> This has definitely been a confusing topic in the past, I completely agree
>> Benedict.  Glad you brought this up.
>> 
>> I'm 100% on board with 5.0 after 4.0.
>> 
>> On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith >> 
>> wrote:
>> 
>>> As a brief side-step on the topic only of versioning (which no doubt will
>>> cause enough consternation), I personally endorse streamlining it.  We
>> have
>>> not had a consistently meaningful convention on this, at any point, and
>> we
>>> made it even worse in the 3.x line.  There's no real difference between
>>> 1.2->2.0, 2.0->2.1, or 3.0->3.11 and 3.11->4.0; let's admit this and go
>>> straight to 5.0 for our next feature release, with 4.1 our first patch
>>> release of the 4.x line.
>>> 
>>> 
 On 08/10/2019, 21:36, "Scott Andreas"  wrote:
>>> 
>>>Re: "How can we decide that *all* new features are suppose to go into
>>> trunk only, if we don’t even have an idea about the upcoming release
>>> schedule?"
>>> 
>>>This is a great question. My understanding of the intent of the
>>> document is that new features are generally expected to land in trunk,
>> with
>>> an exception process defined for feature backports. I think that's a
>>> reasonable expectation to start with. But I also agree with you that it's
>>> important we evolve a way to discuss and agree up on release scope - this
>>> was the focus of my slides at NGCC. I would love to discuss this on a
>>> separate thread.
>>> 
>>>Re: “Bug fix releases have associated new minor version.”
>>>"Patchlevel version" might be more in keeping with our current
>>> convention.
>>> 
>>>Re: "We should give users a way to plan, by having EOL dates"
>>>Incorporating EOL dates into our release management / planning is a
>>> great idea.
>>> 
>>>Would you be willing to rephrase your comments in the form of
>> proposed
>>> edits to the document?
>>> 
>>>– Scott
>>> 
>>>
>>>From: Stefan Podkowinski 
>>>Sent: Tuesday, October 8, 2019 1:22 PM
>>>To: dev@cassandra.apache.org
>>>Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
>>> 
>>> From the document:
>>> 
>>>General Availability (GA): “A new branch is created for the release
>>> with
>>>the new major version, limiting any new feature addition to the new
>>>release branch, with new feature development will continue to happen
>>>only on trunk.”
>>>Maintenance: “Missing features from newer generation releases are
>>>back-ported on per - PMC vote basis.”
>>> 
>>>We had a feature freeze before 4.0, which showed that people have
>>>different views on what actually qualifies as a feature. It doesn’t
>>> work
>>>without defining “feature” in more detail. Although I’d rather avoid
>> to
>>>have this in the document at all, since I don’t think this is getting
>>> us
>>>anywhere, without having a clearer picture on the bigger context in
>>>which release are going to happen in the future, starting with
>> release
>>>cadence and support periods. How can we decide that *all* new
>> features
>>>are suppose to go into trunk only, if we don’t even have an idea
>> about
>>>the upcoming release schedule?
>>> 
>>>“Bug fix releases have associated new minor version.”
>>> 
>>>So the next bug fix version will be 4.1? There will be no minor
>> feature
>>>releases like we did with 3.x.0/2.x.0?
>>> 
>>>Deprecated:
>>>"Through a dev community voting process, EOL date is determined for
>>> this
>>>release.”
>>>“Users actively encouraged to move away from the offering.”
>>> 
>>>We should give users a way to plan, by having EOL dates that may be
>>>months or years ahead in the future. We did this with 3.0 and 2.x,
>>> which
>>>would be all “deprecated” a long time ago with the new proposal.
>>> 
>>>Deprecated: “Only security vulnerabilities and production-impacting
>>> bugs
>>>without workarounds are addressed.”
>>> 
>>>Although devs will define their own definition of
>> “production-impacting
>>>bugs without workarounds” in any way they need, I don’t think we
>> should
>>>have this in the document. It’s okay to use EOLed releases and we
>>> should
>>>not prevent users from contributing smaller fixes, performance
>>>improvements and useful enhancements for minor feature releases.
>>> 
>>>On 08.10.19 20:00, sankalp kohli wrote:
 Hi,
 We have discussed in the email thread[1] about Apache
>> Cassandra
>>> Release
 Lifecycle. We came up with a doc[2] for it. We have finalized the
>> doc
 here[3] Please

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread Joshua McKenzie 
It probably warrants a separate discussion about how we version.

Also, robust +1 to what you said here bes and haddad  ;)

On Tue, Oct 8, 2019 at 5:31 PM Jon Haddad  wrote:

> This has definitely been a confusing topic in the past, I completely agree
> Benedict.  Glad you brought this up.
>
> I'm 100% on board with 5.0 after 4.0.
>
> On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith  >
> wrote:
>
> > As a brief side-step on the topic only of versioning (which no doubt will
> > cause enough consternation), I personally endorse streamlining it.  We
> have
> > not had a consistently meaningful convention on this, at any point, and
> we
> > made it even worse in the 3.x line.  There's no real difference between
> > 1.2->2.0, 2.0->2.1, or 3.0->3.11 and 3.11->4.0; let's admit this and go
> > straight to 5.0 for our next feature release, with 4.1 our first patch
> > release of the 4.x line.
> >
> > 
> > On 08/10/2019, 21:36, "Scott Andreas"  wrote:
> >
> > Re: "How can we decide that *all* new features are suppose to go into
> > trunk only, if we don’t even have an idea about the upcoming release
> > schedule?"
> >
> > This is a great question. My understanding of the intent of the
> > document is that new features are generally expected to land in trunk,
> with
> > an exception process defined for feature backports. I think that's a
> > reasonable expectation to start with. But I also agree with you that it's
> > important we evolve a way to discuss and agree up on release scope - this
> > was the focus of my slides at NGCC. I would love to discuss this on a
> > separate thread.
> >
> > Re: “Bug fix releases have associated new minor version.”
> > "Patchlevel version" might be more in keeping with our current
> > convention.
> >
> > Re: "We should give users a way to plan, by having EOL dates"
> > Incorporating EOL dates into our release management / planning is a
> > great idea.
> >
> > Would you be willing to rephrase your comments in the form of
> proposed
> > edits to the document?
> >
> > – Scott
> >
> > 
> > From: Stefan Podkowinski 
> > Sent: Tuesday, October 8, 2019 1:22 PM
> > To: dev@cassandra.apache.org
> > Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
> >
> >  From the document:
> >
> > General Availability (GA): “A new branch is created for the release
> > with
> > the new major version, limiting any new feature addition to the new
> > release branch, with new feature development will continue to happen
> > only on trunk.”
> > Maintenance: “Missing features from newer generation releases are
> > back-ported on per - PMC vote basis.”
> >
> > We had a feature freeze before 4.0, which showed that people have
> > different views on what actually qualifies as a feature. It doesn’t
> > work
> > without defining “feature” in more detail. Although I’d rather avoid
> to
> > have this in the document at all, since I don’t think this is getting
> > us
> > anywhere, without having a clearer picture on the bigger context in
> > which release are going to happen in the future, starting with
> release
> > cadence and support periods. How can we decide that *all* new
> features
> > are suppose to go into trunk only, if we don’t even have an idea
> about
> > the upcoming release schedule?
> >
> > “Bug fix releases have associated new minor version.”
> >
> > So the next bug fix version will be 4.1? There will be no minor
> feature
> > releases like we did with 3.x.0/2.x.0?
> >
> > Deprecated:
> > "Through a dev community voting process, EOL date is determined for
> > this
> > release.”
> > “Users actively encouraged to move away from the offering.”
> >
> > We should give users a way to plan, by having EOL dates that may be
> > months or years ahead in the future. We did this with 3.0 and 2.x,
> > which
> > would be all “deprecated” a long time ago with the new proposal.
> >
> > Deprecated: “Only security vulnerabilities and production-impacting
> > bugs
> > without workarounds are addressed.”
> >
> > Although devs will define their own definition of
> “production-impacting
> > bugs without workarounds” in any way they need, I don’t think we
> should
> > have this in the document. It’s okay to use EOLed releases and we
> > should
> > not prevent users from contributing smaller fixes, performance
> > improvements and useful enhancements for minor feature releases.
> >
> > On 08.10.19 20:00, sankalp kohli wrote:
> > > Hi,
> > >  We have discussed in the email thread[1] about Apache
> Cassandra
> > Release
> > > Lifecycle. We came up with a doc[2] for it. We have finalized the
> doc
> > > here[3] Please vote on it if you agree with the content of the doc
> > [3].
> > >
> > > We did not proceed with the previous vote as we want to use
> > confluence for

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread Jon Haddad 
This has definitely been a confusing topic in the past, I completely agree
Benedict.  Glad you brought this up.

I'm 100% on board with 5.0 after 4.0.

On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith 
wrote:

> As a brief side-step on the topic only of versioning (which no doubt will
> cause enough consternation), I personally endorse streamlining it.  We have
> not had a consistently meaningful convention on this, at any point, and we
> made it even worse in the 3.x line.  There's no real difference between
> 1.2->2.0, 2.0->2.1, or 3.0->3.11 and 3.11->4.0; let's admit this and go
> straight to 5.0 for our next feature release, with 4.1 our first patch
> release of the 4.x line.
>
> 
> On 08/10/2019, 21:36, "Scott Andreas"  wrote:
>
> Re: "How can we decide that *all* new features are suppose to go into
> trunk only, if we don’t even have an idea about the upcoming release
> schedule?"
>
> This is a great question. My understanding of the intent of the
> document is that new features are generally expected to land in trunk, with
> an exception process defined for feature backports. I think that's a
> reasonable expectation to start with. But I also agree with you that it's
> important we evolve a way to discuss and agree up on release scope - this
> was the focus of my slides at NGCC. I would love to discuss this on a
> separate thread.
>
> Re: “Bug fix releases have associated new minor version.”
> "Patchlevel version" might be more in keeping with our current
> convention.
>
> Re: "We should give users a way to plan, by having EOL dates"
> Incorporating EOL dates into our release management / planning is a
> great idea.
>
> Would you be willing to rephrase your comments in the form of proposed
> edits to the document?
>
> – Scott
>
> 
> From: Stefan Podkowinski 
> Sent: Tuesday, October 8, 2019 1:22 PM
> To: dev@cassandra.apache.org
> Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
>
>  From the document:
>
> General Availability (GA): “A new branch is created for the release
> with
> the new major version, limiting any new feature addition to the new
> release branch, with new feature development will continue to happen
> only on trunk.”
> Maintenance: “Missing features from newer generation releases are
> back-ported on per - PMC vote basis.”
>
> We had a feature freeze before 4.0, which showed that people have
> different views on what actually qualifies as a feature. It doesn’t
> work
> without defining “feature” in more detail. Although I’d rather avoid to
> have this in the document at all, since I don’t think this is getting
> us
> anywhere, without having a clearer picture on the bigger context in
> which release are going to happen in the future, starting with release
> cadence and support periods. How can we decide that *all* new features
> are suppose to go into trunk only, if we don’t even have an idea about
> the upcoming release schedule?
>
> “Bug fix releases have associated new minor version.”
>
> So the next bug fix version will be 4.1? There will be no minor feature
> releases like we did with 3.x.0/2.x.0?
>
> Deprecated:
> "Through a dev community voting process, EOL date is determined for
> this
> release.”
> “Users actively encouraged to move away from the offering.”
>
> We should give users a way to plan, by having EOL dates that may be
> months or years ahead in the future. We did this with 3.0 and 2.x,
> which
> would be all “deprecated” a long time ago with the new proposal.
>
> Deprecated: “Only security vulnerabilities and production-impacting
> bugs
> without workarounds are addressed.”
>
> Although devs will define their own definition of “production-impacting
> bugs without workarounds” in any way they need, I don’t think we should
> have this in the document. It’s okay to use EOLed releases and we
> should
> not prevent users from contributing smaller fixes, performance
> improvements and useful enhancements for minor feature releases.
>
> On 08.10.19 20:00, sankalp kohli wrote:
> > Hi,
> >  We have discussed in the email thread[1] about Apache Cassandra
> Release
> > Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> > here[3] Please vote on it if you agree with the content of the doc
> [3].
> >
> > We did not proceed with the previous vote as we want to use
> confluence for
> > it. Here is the link for that[4]. It also mentions why we are doing
> this
> > vote.
> >
> > Vote will remain open for 72 hours.
> >
> > Thanks,
> > Sankalp
> >
> > [1]
> >
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> > [2]
> >
>

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread Benedict Elliott Smith 
As a brief side-step on the topic only of versioning (which no doubt will cause 
enough consternation), I personally endorse streamlining it.  We have not had a 
consistently meaningful convention on this, at any point, and we made it even 
worse in the 3.x line.  There's no real difference between 1.2->2.0, 2.0->2.1, 
or 3.0->3.11 and 3.11->4.0; let's admit this and go straight to 5.0 for our 
next feature release, with 4.1 our first patch release of the 4.x line. 


On 08/10/2019, 21:36, "Scott Andreas"  wrote:

Re: "How can we decide that *all* new features are suppose to go into trunk 
only, if we don’t even have an idea about the upcoming release schedule?"

This is a great question. My understanding of the intent of the document is 
that new features are generally expected to land in trunk, with an exception 
process defined for feature backports. I think that's a reasonable expectation 
to start with. But I also agree with you that it's important we evolve a way to 
discuss and agree up on release scope - this was the focus of my slides at 
NGCC. I would love to discuss this on a separate thread.

Re: “Bug fix releases have associated new minor version.”
"Patchlevel version" might be more in keeping with our current convention.

Re: "We should give users a way to plan, by having EOL dates"
Incorporating EOL dates into our release management / planning is a great 
idea.

Would you be willing to rephrase your comments in the form of proposed 
edits to the document?

– Scott


From: Stefan Podkowinski 
Sent: Tuesday, October 8, 2019 1:22 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle

 From the document:

General Availability (GA): “A new branch is created for the release with
the new major version, limiting any new feature addition to the new
release branch, with new feature development will continue to happen
only on trunk.”
Maintenance: “Missing features from newer generation releases are
back-ported on per - PMC vote basis.”

We had a feature freeze before 4.0, which showed that people have
different views on what actually qualifies as a feature. It doesn’t work
without defining “feature” in more detail. Although I’d rather avoid to
have this in the document at all, since I don’t think this is getting us
anywhere, without having a clearer picture on the bigger context in
which release are going to happen in the future, starting with release
cadence and support periods. How can we decide that *all* new features
are suppose to go into trunk only, if we don’t even have an idea about
the upcoming release schedule?

“Bug fix releases have associated new minor version.”

So the next bug fix version will be 4.1? There will be no minor feature
releases like we did with 3.x.0/2.x.0?

Deprecated:
"Through a dev community voting process, EOL date is determined for this
release.”
“Users actively encouraged to move away from the offering.”

We should give users a way to plan, by having EOL dates that may be
months or years ahead in the future. We did this with 3.0 and 2.x, which
would be all “deprecated” a long time ago with the new proposal.

Deprecated: “Only security vulnerabilities and production-impacting bugs
without workarounds are addressed.”

Although devs will define their own definition of “production-impacting
bugs without workarounds” in any way they need, I don’t think we should
have this in the document. It’s okay to use EOLed releases and we should
not prevent users from contributing smaller fixes, performance
improvements and useful enhancements for minor feature releases.

On 08.10.19 20:00, sankalp kohli wrote:
> Hi,
>  We have discussed in the email thread[1] about Apache Cassandra 
Release
> Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> here[3] Please vote on it if you agree with the content of the doc [3].
>
> We did not proceed with the previous vote as we want to use confluence for
> it. Here is the link for that[4]. It also mentions why we are doing this
> vote.
>
> Vote will remain open for 72 hours.
>
> Thanks,
> Sankalp
>
> [1]
> 
https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> [2]
> 
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> Attachments area
> [4]
> 
https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
>

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread Scott Andreas 
Re: "How can we decide that *all* new features are suppose to go into trunk 
only, if we don’t even have an idea about the upcoming release schedule?"

This is a great question. My understanding of the intent of the document is 
that new features are generally expected to land in trunk, with an exception 
process defined for feature backports. I think that's a reasonable expectation 
to start with. But I also agree with you that it's important we evolve a way to 
discuss and agree up on release scope - this was the focus of my slides at 
NGCC. I would love to discuss this on a separate thread.

Re: “Bug fix releases have associated new minor version.”
"Patchlevel version" might be more in keeping with our current convention.

Re: "We should give users a way to plan, by having EOL dates"
Incorporating EOL dates into our release management / planning is a great idea.

Would you be willing to rephrase your comments in the form of proposed edits to 
the document?

– Scott


From: Stefan Podkowinski 
Sent: Tuesday, October 8, 2019 1:22 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle

 From the document:

General Availability (GA): “A new branch is created for the release with
the new major version, limiting any new feature addition to the new
release branch, with new feature development will continue to happen
only on trunk.”
Maintenance: “Missing features from newer generation releases are
back-ported on per - PMC vote basis.”

We had a feature freeze before 4.0, which showed that people have
different views on what actually qualifies as a feature. It doesn’t work
without defining “feature” in more detail. Although I’d rather avoid to
have this in the document at all, since I don’t think this is getting us
anywhere, without having a clearer picture on the bigger context in
which release are going to happen in the future, starting with release
cadence and support periods. How can we decide that *all* new features
are suppose to go into trunk only, if we don’t even have an idea about
the upcoming release schedule?

“Bug fix releases have associated new minor version.”

So the next bug fix version will be 4.1? There will be no minor feature
releases like we did with 3.x.0/2.x.0?

Deprecated:
"Through a dev community voting process, EOL date is determined for this
release.”
“Users actively encouraged to move away from the offering.”

We should give users a way to plan, by having EOL dates that may be
months or years ahead in the future. We did this with 3.0 and 2.x, which
would be all “deprecated” a long time ago with the new proposal.

Deprecated: “Only security vulnerabilities and production-impacting bugs
without workarounds are addressed.”

Although devs will define their own definition of “production-impacting
bugs without workarounds” in any way they need, I don’t think we should
have this in the document. It’s okay to use EOLed releases and we should
not prevent users from contributing smaller fixes, performance
improvements and useful enhancements for minor feature releases.

On 08.10.19 20:00, sankalp kohli wrote:
> Hi,
>  We have discussed in the email thread[1] about Apache Cassandra Release
> Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> here[3] Please vote on it if you agree with the content of the doc [3].
>
> We did not proceed with the previous vote as we want to use confluence for
> it. Here is the link for that[4]. It also mentions why we are doing this
> vote.
>
> Vote will remain open for 72 hours.
>
> Thanks,
> Sankalp
>
> [1]
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> [2]
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> Attachments area
> [4]
> https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
> 
>

-
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-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread Stefan Podkowinski 

From the document:

General Availability (GA): “A new branch is created for the release with 
the new major version, limiting any new feature addition to the new 
release branch, with new feature development will continue to happen 
only on trunk.”
Maintenance: “Missing features from newer generation releases are 
back-ported on per - PMC vote basis.”


We had a feature freeze before 4.0, which showed that people have 
different views on what actually qualifies as a feature. It doesn’t work 
without defining “feature” in more detail. Although I’d rather avoid to 
have this in the document at all, since I don’t think this is getting us 
anywhere, without having a clearer picture on the bigger context in 
which release are going to happen in the future, starting with release 
cadence and support periods. How can we decide that *all* new features 
are suppose to go into trunk only, if we don’t even have an idea about 
the upcoming release schedule?


“Bug fix releases have associated new minor version.”

So the next bug fix version will be 4.1? There will be no minor feature 
releases like we did with 3.x.0/2.x.0?


Deprecated:
"Through a dev community voting process, EOL date is determined for this 
release.”

“Users actively encouraged to move away from the offering.”

We should give users a way to plan, by having EOL dates that may be 
months or years ahead in the future. We did this with 3.0 and 2.x, which 
would be all “deprecated” a long time ago with the new proposal.


Deprecated: “Only security vulnerabilities and production-impacting bugs 
without workarounds are addressed.”


Although devs will define their own definition of “production-impacting 
bugs without workarounds” in any way they need, I don’t think we should 
have this in the document. It’s okay to use EOLed releases and we should 
not prevent users from contributing smaller fixes, performance 
improvements and useful enhancements for minor feature releases.


On 08.10.19 20:00, sankalp kohli wrote:

Hi,
 We have discussed in the email thread[1] about Apache Cassandra Release
Lifecycle. We came up with a doc[2] for it. We have finalized the doc
here[3] Please vote on it if you agree with the content of the doc [3].

We did not proceed with the previous vote as we want to use confluence for
it. Here is the link for that[4]. It also mentions why we are doing this
vote.

Vote will remain open for 72 hours.

Thanks,
Sankalp

[1]
https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
[2]
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
[3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
Attachments area
[4]
https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E




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

Re: Can we kick off a release?

2019-10-08 Thread Jon Haddad 
I forgot to mention, we should also release alpha2 of 4.0.


On Tue, Oct 8, 2019 at 1:04 PM Michael Shuler 
wrote:

> Thanks Sam, I'm following #15193 and should catch the status change there.
>
> Michael
>
> On Tue, Oct 8, 2019 at 6:17 AM Sam Tunnicliffe  wrote:
> >
> > CASSANDRA-15193 just got +1’d yesterday and would be good to include in
> the 3.0 and 3.11 releases. If you don’t mind holding off while I add a
> cqlsh test and merge it, that’d be good.
> >
> > Thanks,
> > Sam
> >
> > > On 7 Oct 2019, at 22:54, Michael Shuler 
> wrote:
> > >
> > > Will do! I probably won't get this done this evening, so will send out
> > > the emails tomorrow.
> > >
> > > Thanks,
> > > Michael
> > >
> > > On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad  wrote:
> > >>
> > >> Michael,
> > >>
> > >> Would you mind kicking off builds and starting a vote thread for the
> latest
> > >> 2.2, 3.0 and 3.11 builds?
> > >>
> > >> Much appreciated,
> > >> Jon
> > >
> > > -
> > > 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: Can we kick off a release?

2019-10-08 Thread Michael Shuler 
Thanks Sam, I'm following #15193 and should catch the status change there.

Michael

On Tue, Oct 8, 2019 at 6:17 AM Sam Tunnicliffe  wrote:
>
> CASSANDRA-15193 just got +1’d yesterday and would be good to include in the 
> 3.0 and 3.11 releases. If you don’t mind holding off while I add a cqlsh test 
> and merge it, that’d be good.
>
> Thanks,
> Sam
>
> > On 7 Oct 2019, at 22:54, Michael Shuler  wrote:
> >
> > Will do! I probably won't get this done this evening, so will send out
> > the emails tomorrow.
> >
> > Thanks,
> > Michael
> >
> > On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad  wrote:
> >>
> >> Michael,
> >>
> >> Would you mind kicking off builds and starting a vote thread for the latest
> >> 2.2, 3.0 and 3.11 builds?
> >>
> >> Much appreciated,
> >> Jon
> >
> > -
> > 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-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread Joshua McKenzie 
+1

Don't have comment rights on the confluence article (or am too dense to
figure out _how_ to leave a comment). There's some stringency surrounding
clean CI + no flaky tests that I think bear further discussion; for what
it's worth I'm 100% in support of having hard gatekeeping so quality
doesn't slip, but I've also seen enough proposed cultural changes fail due
to being "big bang" vs. incremental that it worries me a touch. Still a +1
as written though.

On Tue, Oct 8, 2019 at 2:07 PM sankalp kohli  wrote:

> Hi,
> We have discussed in the email thread[1] about Apache Cassandra Release
> Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> here[3] Please vote on it if you agree with the content of the doc [3].
>
> We did not proceed with the previous vote as we want to use confluence for
> it. Here is the link for that[4]. It also mentions why we are doing this
> vote.
>
> Vote will remain open for 72 hours.
>
> Thanks,
> Sankalp
>
> [1]
>
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> [2]
>
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> Attachments area
> [4]
>
> https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
> <
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=gmail#heading=h.633eppni91tw
> >
>

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread Scott Andreas 
+1 nb


From: sankalp kohli 
Sent: Tuesday, October 8, 2019 11:00 AM
To: dev
Subject: [VOTE-2] Apache Cassandra Release Lifecycle

Hi,
We have discussed in the email thread[1] about Apache Cassandra Release
Lifecycle. We came up with a doc[2] for it. We have finalized the doc
here[3] Please vote on it if you agree with the content of the doc [3].

We did not proceed with the previous vote as we want to use confluence for
it. Here is the link for that[4]. It also mentions why we are doing this
vote.

Vote will remain open for 72 hours.

Thanks,
Sankalp

[1]
https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
[2]
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
[3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
Attachments area
[4]
https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E


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

[VOTE-2] Apache Cassandra Release Lifecycle

2019-10-08 Thread sankalp kohli 
Hi,
We have discussed in the email thread[1] about Apache Cassandra Release
Lifecycle. We came up with a doc[2] for it. We have finalized the doc
here[3] Please vote on it if you agree with the content of the doc [3].

We did not proceed with the previous vote as we want to use confluence for
it. Here is the link for that[4]. It also mentions why we are doing this
vote.

Vote will remain open for 72 hours.

Thanks,
Sankalp

[1]
https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
[2]
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
[3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
Attachments area
[4]
https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E

Re: [VOTE] Apache Cassandra Release Lifecycle

2019-10-08 Thread sankalp kohli 
Thanks Sumanth. Let me start another vote

On Tue, Oct 8, 2019 at 7:26 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> Thank you, Scott!
> I've moved the document content (along with outstanding comments) into
> cwiki at
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle.
> Made the GDoc deprecated and view-only, and left breadcrumbs to the cwiki
> in both the jira 
> as
> well as the GDoc
> <
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#
> >
> .
>
> On Mon, Oct 7, 2019 at 12:26 PM Jordan West  wrote:
>
> > +1 nb — to both the document and the benefits listed in Scott’s email.
> >
> > Jordan
> >
> > On Fri, Oct 4, 2019 at 2:26 PM Scott Andreas 
> wrote:
> >
> > > There are two main benefits to agreeing on this:
> > >
> > > 1. Providing clarity for contributors on release phases – i.e., what
> > types
> > > of changes are expected to land or be deferred during a particular
> point
> > in
> > > that cycle.
> > >
> > > 2. Providing semantic clarity to users of Cassandra in terms of what
> they
> > > can expect from a given release.
> > >
> > > The second one is more important. The document stands as a commitment
> > > between the Cassandra project and its users regarding what can be
> > expected
> > > from each type of release. It defines GA releases as "recommended for
> > > production deployment for all users," setting a standard of quality
> that
> > we
> > > aim to uphold together and that users can depend on. Affirming what it
> > > means for a release to be EOL, deprecated, or in maintenance signals
> > > importance of upgrading to a GA version.
> > >
> > > The prerelease phases set expectations for us as contributors to
> produce
> > a
> > > more stable release: what type of testing/validation is needed at what
> > > time, at which point interfaces/protocols solidify, when a release is
> > > considered feature complete, etc.
> > >
> > > Creating clarity for ourselves will help us build a better database,
> and
> > > creating clarity for our users will help give them the confidence to
> run
> > it.
> > >
> > > I want to thank Sumanth for his work on this document and to everyone
> > else
> > > who's contributed.
> > >
> > > I support it (+1 nb).
> > >
> > > – Scott
> > >
> > > 
> > > From: Stefan Podkowinski 
> > > Sent: Tuesday, October 1, 2019 1:43 PM
> > > To: dev@cassandra.apache.org
> > > Subject: Re: [VOTE] Apache Cassandra Release Lifecycle
> > >
> > > What exactly will be the implication of the outcome of this vote, in
> > > case the content is agreed upon? What's the proposal of the voting?
> > >
> > > The document seems to be informative rather then formal. It's verbose
> on
> > > definitions that should be commonly understood or can only broadly
> > > defined (what is alpha/beta/RC, GA for production, etc.), while at the
> > > same time is unclear and weasel-wordy on our actual commitment and
> rules.
> > >
> > >
> > > On 30.09.19 20:51, sankalp kohli wrote:
> > > > Hi,
> > > >  We have discussed in the email thread[1] about Apache Cassandra
> > > Release
> > > > Lifecycle. We came up with a doc[2] for it. Please vote on it if you
> > > agree
> > > > with the content of the doc[2].
> > > >
> > > > Thanks,
> > > > Sankalp
> > > >
> > > > [1]
> > > >
> > >
> >
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> > > > [2]
> > > >
> > >
> >
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> > > >
> > >
> > > -
> > > 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] Apache Cassandra Release Lifecycle

2019-10-08 Thread Sumanth Pasupuleti 
Thank you, Scott!
I've moved the document content (along with outstanding comments) into
cwiki at
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle.
Made the GDoc deprecated and view-only, and left breadcrumbs to the cwiki
in both the jira  as
well as the GDoc

.

On Mon, Oct 7, 2019 at 12:26 PM Jordan West  wrote:

> +1 nb — to both the document and the benefits listed in Scott’s email.
>
> Jordan
>
> On Fri, Oct 4, 2019 at 2:26 PM Scott Andreas  wrote:
>
> > There are two main benefits to agreeing on this:
> >
> > 1. Providing clarity for contributors on release phases – i.e., what
> types
> > of changes are expected to land or be deferred during a particular point
> in
> > that cycle.
> >
> > 2. Providing semantic clarity to users of Cassandra in terms of what they
> > can expect from a given release.
> >
> > The second one is more important. The document stands as a commitment
> > between the Cassandra project and its users regarding what can be
> expected
> > from each type of release. It defines GA releases as "recommended for
> > production deployment for all users," setting a standard of quality that
> we
> > aim to uphold together and that users can depend on. Affirming what it
> > means for a release to be EOL, deprecated, or in maintenance signals
> > importance of upgrading to a GA version.
> >
> > The prerelease phases set expectations for us as contributors to produce
> a
> > more stable release: what type of testing/validation is needed at what
> > time, at which point interfaces/protocols solidify, when a release is
> > considered feature complete, etc.
> >
> > Creating clarity for ourselves will help us build a better database, and
> > creating clarity for our users will help give them the confidence to run
> it.
> >
> > I want to thank Sumanth for his work on this document and to everyone
> else
> > who's contributed.
> >
> > I support it (+1 nb).
> >
> > – Scott
> >
> > 
> > From: Stefan Podkowinski 
> > Sent: Tuesday, October 1, 2019 1:43 PM
> > To: dev@cassandra.apache.org
> > Subject: Re: [VOTE] Apache Cassandra Release Lifecycle
> >
> > What exactly will be the implication of the outcome of this vote, in
> > case the content is agreed upon? What's the proposal of the voting?
> >
> > The document seems to be informative rather then formal. It's verbose on
> > definitions that should be commonly understood or can only broadly
> > defined (what is alpha/beta/RC, GA for production, etc.), while at the
> > same time is unclear and weasel-wordy on our actual commitment and rules.
> >
> >
> > On 30.09.19 20:51, sankalp kohli wrote:
> > > Hi,
> > >  We have discussed in the email thread[1] about Apache Cassandra
> > Release
> > > Lifecycle. We came up with a doc[2] for it. Please vote on it if you
> > agree
> > > with the content of the doc[2].
> > >
> > > Thanks,
> > > Sankalp
> > >
> > > [1]
> > >
> >
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> > > [2]
> > >
> >
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> > >
> >
> > -
> > 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: Can we kick off a release?

2019-10-08 Thread Sam Tunnicliffe 
CASSANDRA-15193 just got +1’d yesterday and would be good to include in the 3.0 
and 3.11 releases. If you don’t mind holding off while I add a cqlsh test and 
merge it, that’d be good.

Thanks,
Sam

> On 7 Oct 2019, at 22:54, Michael Shuler  wrote:
> 
> Will do! I probably won't get this done this evening, so will send out
> the emails tomorrow.
> 
> Thanks,
> Michael
> 
> On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad  wrote:
>> 
>> Michael,
>> 
>> Would you mind kicking off builds and starting a vote thread for the latest
>> 2.2, 3.0 and 3.11 builds?
>> 
>> Much appreciated,
>> Jon
> 
> -
> 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