Re: Proposals for releases - 4.0 and beyond

[Jonathan Haddad]

+1 as well

On Mon, Nov 21, 2016 at 10:59 AM kurt Greaves  wrote:

> yep +1 to this. The LTS release solves my previous concern
>

Re: Proposals for releases - 4.0 and beyond

[kurt Greaves]

yep +1 to this. The LTS release solves my previous concern

Re: Proposals for releases - 4.0 and beyond

[Blake Eggleston]

I really like Stefan's Ubuntu model (because of the LTS release), with 
Sylvain's suggestion a close second. Both because I think we should do a 
supported, non-dev release every 6 months, and release bug fixes for them for a 
at least a year.


On November 19, 2016 at 10:30:02 AM, Stefan Podkowinski (spo...@gmail.com) 
wrote:

I’d like to suggest an option similar to what Jeremiah described and that  
would basically follow the Ubuntu LTS release model [1], but with shorter  
time periods. The idea would be to do a stable release every 6 months with  
1 year bug fixing support. At the same time, every third stable release  
will serve as a LTS release and will be supported for 2 years.  

Have a look at the following gist for illustration:  
https://gist.github.com/spodkowinski/b9659169c73de3231f99bd17f74f5d1f  

As you can see, although the support periods are relatively long, only 3  
releases must be supported at the same time, which should be comparable to  
what is done now.  

At the same time, we also keep doing monthly releases, but they will only  
serve as a milestone for the next stable release. Call them “dev”, “beta”,  
“testing” or whatever you like. Users will be able to start developing for  
those dev releases and deploy to production with the next standard or LTS  
release, after development is finished. Another option for users would be  
to start a project with a standard release and later settle down on a LTS  
release for maintenance only. It's pretty flexible from a user perspective,  
easy to understand and not too much effort to implement from the  
development side.  

On Sat, Nov 19, 2016 at 12:49 AM, Jeff Jirsa   
wrote:  

> With 3.10 voting in progress (take 3), 3.11 in December/January  
> (probably?), we should solidify the plan for 4.0.  
>  
> I went through the archives and found a number of proposals. We (PMC) also  
> had a very brief chat in private to make sure we hadn’t missed any, and  
> here are the proposals that we’ve seen suggested.  
>  
> Option #1: Jon proposed [1] a feature release every 3 months and bugfixes  
> for 6 months after that.  
> Option #2: Mick proposed [2] bimonthly feature, semver, labelling release  
> with stability/quality during voting, 3 GA branches at a time.  
> Option #3: Sylvain proposed [3] feature / testing / stable branches, Y  
> cadence for releases, X month rotation from feature -> testing -> stable ->  
> EOL (X to be determined). This is similar to an Ubuntu/Debian like release  
> schedule – I asked Sylvain for an example just to make sure I understood  
> it, and I’ve copied that to github at [4].  
> Option #4: Jeremiah proposed [5] keeping monthly cadence, and every 12  
> months break off X.0.Y which becomes LTS (same as 3.0.x now). This  
> explicitly excludes alternating tick/tock feature/bugfix for the monthly  
> cadence on the newest/feature/4.x branch.  
> Option #5: Jason proposed a revision to Jeremiah’s proposal such that  
> releases to the LTS branches are NOT tied to a monthly cadence, but are  
> released “as needed”, and the LTS branches are also “as needed”, not tied  
> to a fixed (annual/semi-annual/etc) schedule.  
>  
> Please use this thread as an opportunity to discuss these proposals or  
> feel free to make your own proposals. I think it makes sense to treat this  
> like a nomination phase of an election – let’s allow at least 72 hours for  
> submitting and discussing proposals, and then we’ll open a vote after that.  
>  
> - Jeff  
>  
> [1]: https://lists.apache.org/thread.html/0b2ca82eb8c1235a4e44a406080729  
> be78fb539e1c0cbca638cfff52@%3Cdev.cassandra.apache.org%3E  
> [2]: https://lists.apache.org/thread.html/674ef1c02997041af4b8950023b07b  
> 2f48bce3b197010ef7d7088662@%3Cdev.cassandra.apache.org%3E  
> [3]: https://lists.apache.org/thread.html/fcc4180b7872be4db86eae12b538ee  
> f34c77dcdb5b13987235c8f2bd@%3Cdev.cassandra.apache.org%3E  
> [4]: https://gist.github.com/jeffjirsa/9bee187246ca045689c52ce9caed47bf  
> [5]: https://lists.apache.org/thread.html/0a3372b2f2b30fbeac04f7d5a214b2  
> 03b18f3d69223e7ec9efb64776@%3Cdev.cassandra.apache.org%3E  
>  
>  
>  
>  
>  

Re: Proposals for releases - 4.0 and beyond

[Mick Semb Wever]

On 19 November 2016 at 10:49, Jeff Jirsa  wrote:

> Option #3: Sylvain proposed [3] feature / testing / stable branches, Y
> cadence for releases, X month rotation from feature -> testing -> stable ->
> EOL (X to be determined). This is similar to an Ubuntu/Debian like release
> schedule – I asked Sylvain for an example just to make sure I understood
> it, and I’ve copied that to github at [4].



+1

~mck

Re: Proposals for releases - 4.0 and beyond

[Stefan Podkowinski]

I’d like to suggest an option similar to what Jeremiah described and that
would basically follow the Ubuntu LTS release model [1], but with shorter
time periods. The idea would be to do a stable release every 6 months with
1 year bug fixing support. At the same time, every third stable release
will serve as a LTS release and will be supported for 2 years.

Have a look at the following gist for illustration:
https://gist.github.com/spodkowinski/b9659169c73de3231f99bd17f74f5d1f

As you can see, although the support periods are relatively long, only 3
releases must be supported at the same time, which should be comparable to
what is done now.

At the same time, we also keep doing monthly releases, but they will only
serve as a milestone for the next stable release. Call them “dev”, “beta”,
“testing” or whatever you like. Users will be able to start developing for
those dev releases and deploy to production with the next standard or LTS
release, after development is finished. Another option for users would be
to start a project with a standard release and later settle down on a LTS
release for maintenance only. It's pretty flexible from a user perspective,
easy to understand and not too much effort to implement from the
development side.

On Sat, Nov 19, 2016 at 12:49 AM, Jeff Jirsa 
wrote:

> With 3.10 voting in progress (take 3), 3.11 in December/January
> (probably?), we should solidify the plan for 4.0.
>
> I went through the archives and found a number of proposals. We (PMC) also
> had a very brief chat in private to make sure we hadn’t missed any, and
> here are the proposals that we’ve seen suggested.
>
> Option #1: Jon proposed [1] a feature release every 3 months and bugfixes
> for 6 months after that.
> Option #2: Mick proposed [2] bimonthly feature, semver, labelling release
> with stability/quality during voting, 3 GA branches at a time.
> Option #3: Sylvain proposed [3] feature / testing / stable branches, Y
> cadence for releases, X month rotation from feature -> testing -> stable ->
> EOL (X to be determined). This is similar to an Ubuntu/Debian like release
> schedule – I asked Sylvain for an example just to make sure I understood
> it, and I’ve copied that to github at [4].
> Option #4: Jeremiah proposed [5] keeping monthly cadence, and every 12
> months break off X.0.Y which becomes LTS (same as 3.0.x now). This
> explicitly excludes alternating tick/tock feature/bugfix for the monthly
> cadence on the newest/feature/4.x branch.
> Option #5: Jason proposed a revision to Jeremiah’s proposal such that
> releases to the LTS branches are NOT tied to a monthly cadence, but are
> released “as needed”, and the LTS branches are also “as needed”, not tied
> to a fixed (annual/semi-annual/etc) schedule.
>
> Please use this thread as an opportunity to discuss these proposals or
> feel free to make your own proposals. I think it makes sense to treat this
> like a nomination phase of an election – let’s allow at least 72 hours for
> submitting and discussing proposals, and then we’ll open a vote after that.
>
> - Jeff
>
> [1]: https://lists.apache.org/thread.html/0b2ca82eb8c1235a4e44a406080729
> be78fb539e1c0cbca638cfff52@%3Cdev.cassandra.apache.org%3E
> [2]: https://lists.apache.org/thread.html/674ef1c02997041af4b8950023b07b
> 2f48bce3b197010ef7d7088662@%3Cdev.cassandra.apache.org%3E
> [3]: https://lists.apache.org/thread.html/fcc4180b7872be4db86eae12b538ee
> f34c77dcdb5b13987235c8f2bd@%3Cdev.cassandra.apache.org%3E
> [4]: https://gist.github.com/jeffjirsa/9bee187246ca045689c52ce9caed47bf
> [5]: https://lists.apache.org/thread.html/0a3372b2f2b30fbeac04f7d5a214b2
> 03b18f3d69223e7ec9efb64776@%3Cdev.cassandra.apache.org%3E
>
>
>
>
>

Re: Proposals for releases - 4.0 and beyond

[Samuel CARRIERE]

Hi,

I do like Sylvain's proposal too.
And, from a user perspective, I agree with Kurt that having (at least) 2 
"bug fixing only" branches instead of 1 would be great.




De :kurt Greaves <k...@instaclustr.com>
A : dev@cassandra.apache.org, 
Date :  19/11/2016 07:42
Objet : Re: Proposals for releases - 4.0 and beyond



Option 3 seems the most reasonable and the clearest from a user
perspective. The main thing I'd be concerned about with a 6 month cycle
would be how short a branch is supported for. Most users will be bound to 
a
specific release for at least 2 years, and we still find bugs in 2.1 2
years since release. The only adjustment I would make would be to support
branches for 1.5 - 2 years before EOL.

Re: Proposals for releases - 4.0 and beyond

[kurt Greaves]

Option 3 seems the most reasonable and the clearest from a user
perspective. The main thing I'd be concerned about with a 6 month cycle
would be how short a branch is supported for. Most users will be bound to a
specific release for at least 2 years, and we still find bugs in 2.1 2
years since release. The only adjustment I would make would be to support
branches for 1.5 - 2 years before EOL.

Re: Proposals for releases - 4.0 and beyond

[Jeremiah D Jordan]

I think the monthly releases are important, otherwise releases become an 
“event”.  The monthly releases mean they are just a normal thing that happens.  
So I like any of 3/4/5.

Sylvain's proposal sounds interesting to me.  My only concern would be with 
making sure we label things very clearly so that users understand which branch 
is the current “stable” branch.  The switch from “testing” to “stable” seems 
like a place that could cause confusion, but as long as we label everything 
well I think we can handle it.

That being said, I think it would be a good addition to the current model 
making the “wait for .6 for stable” more explicit in the release plan, since 
this is what many users already do on their own.

So I think I like Option 3 most of them.  It keeps a monthly cadence, it makes 
explicit which branch we think is stable, and it keeps the number of active 
branches manageable.

-Jeremiah


> On Nov 18, 2016, at 5:49 PM, Jeff Jirsa  wrote:
> 
> With 3.10 voting in progress (take 3), 3.11 in December/January (probably?), 
> we should solidify the plan for 4.0.
> 
> I went through the archives and found a number of proposals. We (PMC) also 
> had a very brief chat in private to make sure we hadn’t missed any, and here 
> are the proposals that we’ve seen suggested. 
> 
> Option #1: Jon proposed [1] a feature release every 3 months and bugfixes for 
> 6 months after that.
> Option #2: Mick proposed [2] bimonthly feature, semver, labelling release 
> with stability/quality during voting, 3 GA branches at a time. 
> Option #3: Sylvain proposed [3] feature / testing / stable branches, Y 
> cadence for releases, X month rotation from feature -> testing -> stable -> 
> EOL (X to be determined). This is similar to an Ubuntu/Debian like release 
> schedule – I asked Sylvain for an example just to make sure I understood it, 
> and I’ve copied that to github at [4].
> Option #4: Jeremiah proposed [5] keeping monthly cadence, and every 12 months 
> break off X.0.Y which becomes LTS (same as 3.0.x now). This explicitly 
> excludes alternating tick/tock feature/bugfix for the monthly cadence on the 
> newest/feature/4.x branch. 
> Option #5: Jason proposed a revision to Jeremiah’s proposal such that 
> releases to the LTS branches are NOT tied to a monthly cadence, but are 
> released “as needed”, and the LTS branches are also “as needed”, not tied to 
> a fixed (annual/semi-annual/etc) schedule. 
> 
> Please use this thread as an opportunity to discuss these proposals or feel 
> free to make your own proposals. I think it makes sense to treat this like a 
> nomination phase of an election – let’s allow at least 72 hours for 
> submitting and discussing proposals, and then we’ll open a vote after that.
>   
> - Jeff
> 
> [1]: 
> https://lists.apache.org/thread.html/0b2ca82eb8c1235a4e44a406080729be78fb539e1c0cbca638cfff52@%3Cdev.cassandra.apache.org%3E
> [2]: 
> https://lists.apache.org/thread.html/674ef1c02997041af4b8950023b07b2f48bce3b197010ef7d7088662@%3Cdev.cassandra.apache.org%3E
> [3]: 
> https://lists.apache.org/thread.html/fcc4180b7872be4db86eae12b538eef34c77dcdb5b13987235c8f2bd@%3Cdev.cassandra.apache.org%3E
> [4]: https://gist.github.com/jeffjirsa/9bee187246ca045689c52ce9caed47bf
> [5]: 
> https://lists.apache.org/thread.html/0a3372b2f2b30fbeac04f7d5a214b203b18f3d69223e7ec9efb64776@%3Cdev.cassandra.apache.org%3E
> 
> 
> 
>