Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-11 Thread sankalp kohli 
Vote passes with 11 +1 and no -1

On Thu, Oct 10, 2019 at 2:41 PM Jordan West  wrote:

> +1 nb
>
> On Wed, Oct 9, 2019 at 11:00 PM Per Otterström
>  wrote:
>
> > +1 nb
> >
> > -Original Message-
> > From: Mick Semb Wever 
> > Sent: den 10 oktober 2019 07:08
> > To: dev@cassandra.apache.org
> > Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
> >
> >
> > > 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].
> >
> >
> > +1 nb
> >
> > the doc is good. it adds value for users, and does not need to be
> perfect.
> > thanks Sumanth for doing this.
> >
> >
> > -
> > 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-10 Thread Jordan West 
+1 nb

On Wed, Oct 9, 2019 at 11:00 PM Per Otterström
 wrote:

> +1 nb
>
> -Original Message-
> From: Mick Semb Wever 
> Sent: den 10 oktober 2019 07:08
> To: dev@cassandra.apache.org
> Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
>
>
> > 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].
>
>
> +1 nb
>
> the doc is good. it adds value for users, and does not need to be perfect.
> thanks Sumanth for doing this.
>
>
> -
> 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-10 Thread Per Otterström 
+1 nb

-Original Message-
From: Mick Semb Wever  
Sent: den 10 oktober 2019 07:08
To: dev@cassandra.apache.org
Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle


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


+1 nb

the doc is good. it adds value for users, and does not need to be perfect.
thanks Sumanth for doing this.


-
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-09 Thread Mick Semb Wever 


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


+1 nb

the doc is good. it adds value for users, and does not need to be perfect.
thanks Sumanth for doing this.


-
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-09 Thread Dinesh Joshi 
+1, lets evolve the document as we gain more experience with the proposed 
release lifecycle.

Dinesh

> On Oct 9, 2019, at 9:41 AM, Jon Haddad  wrote:
> 
> +1 works for me
> 
> On Wed, Oct 9, 2019 at 9:30 AM Michael Shuler 
> wrote:
> 
>> +1
>> 
>> --
>> Kind regards,
>> Michael
>> 
>> On Wed, Oct 9, 2019 at 9:06 AM Aleksey Yeshchenko
>>  wrote:
>>> 
>>> +1 as a rather reasonable starting point; we can make changes to the
>> process in the future if need be.
>>> 
 On 8 Oct 2019, at 19: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
 <
>> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=gmail#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
>> 
>> 


-
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-09 Thread Michael Shuler 
+1

-- 
Kind regards,
Michael

On Wed, Oct 9, 2019 at 9:06 AM Aleksey Yeshchenko
 wrote:
>
> +1 as a rather reasonable starting point; we can make changes to the process 
> in the future if need be.
>
> > On 8 Oct 2019, at 19: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-09 Thread Aleksey Yeshchenko 
+1 as a rather reasonable starting point; we can make changes to the process in 
the future if need be.

> On 8 Oct 2019, at 19: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: [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.”
>>>

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 fu

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

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

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/169b00f

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
> <https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=gmail#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-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: [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
<https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=gmail#heading=h.633eppni91tw>

-
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