You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jeff Jirsa <je...@crowdstrike.com> on 2016/11/18 23:49:43 UTC
Proposals for releases - 4.0 and beyond
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
Re: Proposals for releases - 4.0 and beyond
Posted by Jonathan Haddad <jo...@jonhaddad.com>.
+1 as well
On Mon, Nov 21, 2016 at 10:59 AM kurt Greaves <ku...@instaclustr.com> wrote:
> yep +1 to this. The LTS release solves my previous concern
>
Re: Proposals for releases - 4.0 and beyond
Posted by kurt Greaves <ku...@instaclustr.com>.
yep +1 to this. The LTS release solves my previous concern
Re: Proposals for releases - 4.0 and beyond
Posted by Blake Eggleston <be...@apple.com>.
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 (spodxx@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 <je...@crowdstrike.com>
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
Posted by Stefan Podkowinski <sp...@gmail.com>.
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 <je...@crowdstrike.com>
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
Posted by Samuel CARRIERE <sa...@urssaf.fr>.
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 <ku...@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
Posted by kurt Greaves <ku...@instaclustr.com>.
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
Posted by Jeremiah D Jordan <je...@gmail.com>.
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 <Je...@crowdstrike.com> 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
>
>
>
>
Re: Proposals for releases - 4.0 and beyond
Posted by Mick Semb Wever <mi...@thelastpickle.com>.
On 19 November 2016 at 10:49, Jeff Jirsa <je...@crowdstrike.com> 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