You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Maciek Sakrejda <ma...@heroku.com> on 2016/01/11 04:29:41 UTC
Versioning policy?
There was a discussion recently about changing the Cassandra EOL policy on
the users list [1], but it didn't really go anywhere. I wanted to ask here
instead to clear up the status quo first. What's the current versioning
policy? The tick-tock versioning blog post [2] states in passing that two
major releases are maintained, but I have not found this as an official
policy stated anywhere. For comparison, the Postgres project lays this out
very clearly [3]. To be clear, I'm not looking for any official support,
I'm just asking for clarification regarding the maintenance policy: if a
critical bug or security vulnerability is found in version X.Y.Z, when can
I expect it to be fixed in a bugfix patch to that major version, and when
do I need to upgrade to the next major version.
[1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
[2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
[3]: http://www.postgresql.org/support/versioning/
Re: Versioning policy?
Posted by Jack Krupansky <ja...@gmail.com>.
Mark, what would the policy dictate if the bug is in a feature that was
introduced in 3.x and the feature wasn't in 3.0 and the current release is
3.x+k where k is greater than two - technically 3.x is no longer supported,
so does that mean no backporting of the fix and only 3.x+k+1 would get the
bug fix (or maybe 3.x+k-1.y in your rare cases)? In this case the user on
3.x would have to upgrade more than two releases to get the big fix even
though 3.x may only have been released a few months earlier. I think this
is the gist of the original discussion that the EOL policy for 3.x is way
too short for more conservative customers.
Maybe the right answer for them is to only use x.0.z releases and not use
features introduced in x.y releases. But even then... if they adopt 3.0.z
just a month or two before x+1.0 comes out they are back in that same boat
that no matter what release they pick it will go EOL within just a few
months.
-- Jack Krupansky
On Thu, Jan 14, 2016 at 11:39 AM, Mark Dewey <mi...@gmail.com> wrote:
> Let's do a couple examples:
>
> 1. Current release: 3.4.0, bug found in 3.1.0 that also exists in
> subsequent versions; the bug fix will be ported back to 3.0.x and 3.5.0.
> 2. Current release 3.3.0, bug found in 3.3.0; the bug fix will be ported
> back to 3.0.x and 3.4.0. In rare cases, a 3.3.1 may also be released
> (we've
> already seen one example of this).
> 3. Current release 3.6.0, bug found in 3.1.0; the bug fix will be ported
> back to 3.0.x and 3.7.
>
> Essentially, any bug fixes will be released in the next minor version and
> backported to the 3.0.x branches (unless the feature doesn't exist in 3.0).
> We have seen one instance where we released a point version as well, but
> that was for a major regression that was discovered almost immediately
> after a release.
>
> On Wed, Jan 13, 2016 at 12:55 PM Maciek Sakrejda <ma...@heroku.com>
> wrote:
>
> > Can anyone chime in here? We're getting ready to run a decent number of
> > nodes; we'd like to have a better idea of what to expect with respect to
> > patching and upgrading. A clear versioning policy like the one laid out
> by
> > Postgres would be very helpful.
> >
> >
>
Re: Versioning policy?
Posted by Mark Dewey <mi...@gmail.com>.
Let's do a couple examples:
1. Current release: 3.4.0, bug found in 3.1.0 that also exists in
subsequent versions; the bug fix will be ported back to 3.0.x and 3.5.0.
2. Current release 3.3.0, bug found in 3.3.0; the bug fix will be ported
back to 3.0.x and 3.4.0. In rare cases, a 3.3.1 may also be released (we've
already seen one example of this).
3. Current release 3.6.0, bug found in 3.1.0; the bug fix will be ported
back to 3.0.x and 3.7.
Essentially, any bug fixes will be released in the next minor version and
backported to the 3.0.x branches (unless the feature doesn't exist in 3.0).
We have seen one instance where we released a point version as well, but
that was for a major regression that was discovered almost immediately
after a release.
On Wed, Jan 13, 2016 at 12:55 PM Maciek Sakrejda <ma...@heroku.com> wrote:
> Can anyone chime in here? We're getting ready to run a decent number of
> nodes; we'd like to have a better idea of what to expect with respect to
> patching and upgrading. A clear versioning policy like the one laid out by
> Postgres would be very helpful.
>
>
Re: Versioning policy?
Posted by Maciek Sakrejda <ma...@heroku.com>.
Can anyone chime in here? We're getting ready to run a decent number of
nodes; we'd like to have a better idea of what to expect with respect to
patching and upgrading. A clear versioning policy like the one laid out by
Postgres would be very helpful.
Re: Versioning policy?
Posted by Anuj Wadehra <an...@yahoo.co.in>.
HAPPY to see that Apache Cassandra web site has been updated to include EOL information :) Thanks !!!
I have some queries on the updated content:
1. Earlier, Apache web site always used to show 2 Cassandra versions - one which is "most stable" (production-ready) and other for development use. Now, I can't see that "most stable"(production-ready) tag on any version.
Site says "The latest tick-tock release is 3.2"
As per the tick-tock logic, Does that mean 3.1 is the latest most stable Cassandra version available today as it had bug-fixes for 3.0 ? Is 3.1 production ready? If NO, then how would production users on earlier releases get indication on their next upgrade version e.g. 3.x or 2.2 ?
2. I am assuming that going forward EOL announcements will be published at the Apache web site before hand just like some other Apache projects do. Is that assumption valid?
It will certainly help to get such insights before hand on Apache site so that community users can prepare their upgrade road map.
ThanksAnuj
On Sunday, 17 January 2016 12:48 AM, Anuj Wadehra <an...@yahoo.co.in> wrote:
Hi Jonathan
It would be really nice if you could share your thoughts on the four points raised regarding the Cassandra EOL process. I think similar things happen for other open source products and it would be really nice if we could streamline such things for Apache Cassandra.
ThanksAnuj
Sent from Yahoo Mail on Android
On Thu, 14 Jan, 2016 at 11:28 pm, Anuj Wadehra<an...@yahoo.co.in> wrote: Hi Jonathan,
Thanks for the crisp communication regarding the tick tock release & EOL.
I think its worth considering some points regarding EOL policy and it would be great if you can share your thoughts on below points:
1. EOL of a release should be based on "most stable"/"production ready" version date rather than "GA" date of subsequent major releases.
2. I think we should have "Formal EOL Announcement" on Apache Cassandra website.
3. "Formal EOL Announcement" should come at least 6 months before the EOL, so that users get reasonable time to upgrade.
4. EOL Policy (even if flexible) should be stated on Apache Cassandra website
EOL thread on users mailing list ended with the conclusion of raising a Wishlist JIRA but I think above points are more about working on policy and processes rather than just a wish list.
ThanksAnuj
Sent from Yahoo Mail on Android
On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis<jb...@gmail.com> wrote: Hi Maciek,
First let's talk about the tick-tock series, currently 3.x. This is pretty
simple: outside of the regular monthly releases, we will release fixes for
critical bugs against the most recent bugfix release, the way we did
recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases
will be patched.
Now, we also have three other release series currently being supported:
2.1.x: supported with critical fixes only until 4.0 is released, projected
in November 2016 [2]
2.2.x: maintained until 4.0 is released
3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
I will add this information to the releases page [3].
[1]
https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690PZpozA@mail.gmail.com%3E
[2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
sunsetting deprecated features like Thrift so bumping the major version
seems appropriate
[3] http://cassandra.apache.org/download/
On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda <ma...@heroku.com> wrote:
> There was a discussion recently about changing the Cassandra EOL policy on
> the users list [1], but it didn't really go anywhere. I wanted to ask here
> instead to clear up the status quo first. What's the current versioning
> policy? The tick-tock versioning blog post [2] states in passing that two
> major releases are maintained, but I have not found this as an official
> policy stated anywhere. For comparison, the Postgres project lays this out
> very clearly [3]. To be clear, I'm not looking for any official support,
> I'm just asking for clarification regarding the maintenance policy: if a
> critical bug or security vulnerability is found in version X.Y.Z, when can
> I expect it to be fixed in a bugfix patch to that major version, and when
> do I need to upgrade to the next major version.
>
> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
> [3]: http://www.postgresql.org/support/versioning/
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Versioning policy?
Posted by Anuj Wadehra <an...@yahoo.co.in>.
I was not referring to Enterprise support here. When I said Open source "product" by mistake, I was just referring to some other Apache open source projects like Apache Cassandra where you get EOL announcements, info etc on the main Apache web site. I think all four points are very relevant in context of an Open source project and thats why I wanted to thoughts on these points.
ThanksAnuj
Sent from Yahoo Mail on Android
On Sun, 17 Jan, 2016 at 1:43 am, Michael Kjellman<mk...@internalcircle.com> wrote: Correct, this is an open source project.
If you want a Enterprise support story Datastax has an Enterprise option for you.
> On Jan 16, 2016, at 11:19 AM, Anuj Wadehra <an...@yahoo.co.in> wrote:
>
> Hi Jonathan
>
> It would be really nice if you could share your thoughts on the four points raised regarding the Cassandra EOL process. I think similar things happen for other open source products and it would be really nice if we could streamline such things for Apache Cassandra.
>
> ThanksAnuj
>
> Sent from Yahoo Mail on Android
>
> On Thu, 14 Jan, 2016 at 11:28 pm, Anuj Wadehra<an...@yahoo.co.in> wrote: Hi Jonathan,
> Thanks for the crisp communication regarding the tick tock release & EOL.
> I think its worth considering some points regarding EOL policy and it would be great if you can share your thoughts on below points:
> 1. EOL of a release should be based on "most stable"/"production ready" version date rather than "GA" date of subsequent major releases.
> 2. I think we should have "Formal EOL Announcement" on Apache Cassandra website.
> 3. "Formal EOL Announcement" should come at least 6 months before the EOL, so that users get reasonable time to upgrade.
> 4. EOL Policy (even if flexible) should be stated on Apache Cassandra website
>
> EOL thread on users mailing list ended with the conclusion of raising a Wishlist JIRA but I think above points are more about working on policy and processes rather than just a wish list.
>
> ThanksAnuj
>
>
>
> Sent from Yahoo Mail on Android
>
> On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis<jb...@gmail.com> wrote: Hi Maciek,
>
> First let's talk about the tick-tock series, currently 3.x. This is pretty
> simple: outside of the regular monthly releases, we will release fixes for
> critical bugs against the most recent bugfix release, the way we did
> recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases
> will be patched.
>
> Now, we also have three other release series currently being supported:
>
> 2.1.x: supported with critical fixes only until 4.0 is released, projected
> in November 2016 [2]
> 2.2.x: maintained until 4.0 is released
> 3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
>
> I will add this information to the releases page [3].
>
> [1]
> https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690PZpozA@mail.gmail.com%3E
> [2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
> sunsetting deprecated features like Thrift so bumping the major version
> seems appropriate
> [3] http://cassandra.apache.org/download/
>
>> On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda <ma...@heroku.com> wrote:
>>
>> There was a discussion recently about changing the Cassandra EOL policy on
>> the users list [1], but it didn't really go anywhere. I wanted to ask here
>> instead to clear up the status quo first. What's the current versioning
>> policy? The tick-tock versioning blog post [2] states in passing that two
>> major releases are maintained, but I have not found this as an official
>> policy stated anywhere. For comparison, the Postgres project lays this out
>> very clearly [3]. To be clear, I'm not looking for any official support,
>> I'm just asking for clarification regarding the maintenance policy: if a
>> critical bug or security vulnerability is found in version X.Y.Z, when can
>> I expect it to be fixed in a bugfix patch to that major version, and when
>> do I need to upgrade to the next major version.
>>
>> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
>> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
>> [3]: http://www.postgresql.org/support/versioning/
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
Re: Versioning policy?
Posted by Michael Kjellman <mk...@internalcircle.com>.
Correct, this is an open source project.
If you want a Enterprise support story Datastax has an Enterprise option for you.
> On Jan 16, 2016, at 11:19 AM, Anuj Wadehra <an...@yahoo.co.in> wrote:
>
> Hi Jonathan
>
> It would be really nice if you could share your thoughts on the four points raised regarding the Cassandra EOL process. I think similar things happen for other open source products and it would be really nice if we could streamline such things for Apache Cassandra.
>
> ThanksAnuj
>
> Sent from Yahoo Mail on Android
>
> On Thu, 14 Jan, 2016 at 11:28 pm, Anuj Wadehra<an...@yahoo.co.in> wrote: Hi Jonathan,
> Thanks for the crisp communication regarding the tick tock release & EOL.
> I think its worth considering some points regarding EOL policy and it would be great if you can share your thoughts on below points:
> 1. EOL of a release should be based on "most stable"/"production ready" version date rather than "GA" date of subsequent major releases.
> 2. I think we should have "Formal EOL Announcement" on Apache Cassandra website.
> 3. "Formal EOL Announcement" should come at least 6 months before the EOL, so that users get reasonable time to upgrade.
> 4. EOL Policy (even if flexible) should be stated on Apache Cassandra website
>
> EOL thread on users mailing list ended with the conclusion of raising a Wishlist JIRA but I think above points are more about working on policy and processes rather than just a wish list.
>
> ThanksAnuj
>
>
>
> Sent from Yahoo Mail on Android
>
> On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis<jb...@gmail.com> wrote: Hi Maciek,
>
> First let's talk about the tick-tock series, currently 3.x. This is pretty
> simple: outside of the regular monthly releases, we will release fixes for
> critical bugs against the most recent bugfix release, the way we did
> recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases
> will be patched.
>
> Now, we also have three other release series currently being supported:
>
> 2.1.x: supported with critical fixes only until 4.0 is released, projected
> in November 2016 [2]
> 2.2.x: maintained until 4.0 is released
> 3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
>
> I will add this information to the releases page [3].
>
> [1]
> https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690PZpozA@mail.gmail.com%3E
> [2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
> sunsetting deprecated features like Thrift so bumping the major version
> seems appropriate
> [3] http://cassandra.apache.org/download/
>
>> On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda <ma...@heroku.com> wrote:
>>
>> There was a discussion recently about changing the Cassandra EOL policy on
>> the users list [1], but it didn't really go anywhere. I wanted to ask here
>> instead to clear up the status quo first. What's the current versioning
>> policy? The tick-tock versioning blog post [2] states in passing that two
>> major releases are maintained, but I have not found this as an official
>> policy stated anywhere. For comparison, the Postgres project lays this out
>> very clearly [3]. To be clear, I'm not looking for any official support,
>> I'm just asking for clarification regarding the maintenance policy: if a
>> critical bug or security vulnerability is found in version X.Y.Z, when can
>> I expect it to be fixed in a bugfix patch to that major version, and when
>> do I need to upgrade to the next major version.
>>
>> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
>> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
>> [3]: http://www.postgresql.org/support/versioning/
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
Re: Versioning policy?
Posted by Anuj Wadehra <an...@yahoo.co.in>.
Hi Jonathan
It would be really nice if you could share your thoughts on the four points raised regarding the Cassandra EOL process. I think similar things happen for other open source products and it would be really nice if we could streamline such things for Apache Cassandra.
ThanksAnuj
Sent from Yahoo Mail on Android
On Thu, 14 Jan, 2016 at 11:28 pm, Anuj Wadehra<an...@yahoo.co.in> wrote: Hi Jonathan,
Thanks for the crisp communication regarding the tick tock release & EOL.
I think its worth considering some points regarding EOL policy and it would be great if you can share your thoughts on below points:
1. EOL of a release should be based on "most stable"/"production ready" version date rather than "GA" date of subsequent major releases.
2. I think we should have "Formal EOL Announcement" on Apache Cassandra website.
3. "Formal EOL Announcement" should come at least 6 months before the EOL, so that users get reasonable time to upgrade.
4. EOL Policy (even if flexible) should be stated on Apache Cassandra website
EOL thread on users mailing list ended with the conclusion of raising a Wishlist JIRA but I think above points are more about working on policy and processes rather than just a wish list.
ThanksAnuj
Sent from Yahoo Mail on Android
On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis<jb...@gmail.com> wrote: Hi Maciek,
First let's talk about the tick-tock series, currently 3.x. This is pretty
simple: outside of the regular monthly releases, we will release fixes for
critical bugs against the most recent bugfix release, the way we did
recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases
will be patched.
Now, we also have three other release series currently being supported:
2.1.x: supported with critical fixes only until 4.0 is released, projected
in November 2016 [2]
2.2.x: maintained until 4.0 is released
3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
I will add this information to the releases page [3].
[1]
https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690PZpozA@mail.gmail.com%3E
[2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
sunsetting deprecated features like Thrift so bumping the major version
seems appropriate
[3] http://cassandra.apache.org/download/
On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda <ma...@heroku.com> wrote:
> There was a discussion recently about changing the Cassandra EOL policy on
> the users list [1], but it didn't really go anywhere. I wanted to ask here
> instead to clear up the status quo first. What's the current versioning
> policy? The tick-tock versioning blog post [2] states in passing that two
> major releases are maintained, but I have not found this as an official
> policy stated anywhere. For comparison, the Postgres project lays this out
> very clearly [3]. To be clear, I'm not looking for any official support,
> I'm just asking for clarification regarding the maintenance policy: if a
> critical bug or security vulnerability is found in version X.Y.Z, when can
> I expect it to be fixed in a bugfix patch to that major version, and when
> do I need to upgrade to the next major version.
>
> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
> [3]: http://www.postgresql.org/support/versioning/
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Versioning policy?
Posted by Jonathan Ellis <jb...@gmail.com>.
4.0 will be an ordinary tick-tock release after 3.11, but we will be
sunsetting deprecated features like Thrift so bumping the major version
seems appropriate.
On Thu, Jan 14, 2016 at 5:56 PM, Jack Krupansky <ja...@gmail.com>
wrote:
> Thanks, Jonathan. The end-of-life (EOL) question is still dangling out
> there - when does 3.x go off support, after 3.x+3 or six months after 4.0?
> Or... six months after 5.0?
>
>
> -- Jack Krupansky
>
> On Thu, Jan 14, 2016 at 6:15 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>
> > On Thu, Jan 14, 2016 at 4:26 PM, Jack Krupansky <
> jack.krupansky@gmail.com>
> > wrote:
> >
> > > Jonathan, just to complete the list, it would be help to state:
> > >
> > > 3.1.x will be maintained until <what>
> > > 3.2 will be maintained until <what>
> > >
> >
> > One of the confusing things about tick tock is that we're stuck with
> > numbers that look like the old ones but mean different things.
> >
> > In the old world, 2.1 was a release that took a year of work, and it got
> > maintained with roughly-monthly updates of 2.1.x.
> >
> > In the tick tock world, the corresponding series is just "3," and the
> > monthly updates are 3.1, 3.2, and so forth, with new features allowed in
> > the even releases every two months. So in general, there will be no
> 3.1.x
> > or 3.2.y releases. When a bug is critical enough to make an exception to
> > the "wait for the next monthly release" rule, it will be fixed in the
> most
> > recent bugfix tock.
> >
> > will tick-tock completely replace that "traditional"
> > > section?
> >
> >
> > Yes.
> >
> >
> > > In which case, the question of criteria for defining "stable
> > > release" remains, unless it becomes no different than the latest
> > tick-tock
> > > release.
> > >
> >
> > That's the idea, and that's why we're getting very religious about test
> > engineering, so that those monthly releases will always be stable.
> >
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Versioning policy?
Posted by Jack Krupansky <ja...@gmail.com>.
Thanks, Jonathan. The end-of-life (EOL) question is still dangling out
there - when does 3.x go off support, after 3.x+3 or six months after 4.0?
Or... six months after 5.0?
-- Jack Krupansky
On Thu, Jan 14, 2016 at 6:15 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Thu, Jan 14, 2016 at 4:26 PM, Jack Krupansky <ja...@gmail.com>
> wrote:
>
> > Jonathan, just to complete the list, it would be help to state:
> >
> > 3.1.x will be maintained until <what>
> > 3.2 will be maintained until <what>
> >
>
> One of the confusing things about tick tock is that we're stuck with
> numbers that look like the old ones but mean different things.
>
> In the old world, 2.1 was a release that took a year of work, and it got
> maintained with roughly-monthly updates of 2.1.x.
>
> In the tick tock world, the corresponding series is just "3," and the
> monthly updates are 3.1, 3.2, and so forth, with new features allowed in
> the even releases every two months. So in general, there will be no 3.1.x
> or 3.2.y releases. When a bug is critical enough to make an exception to
> the "wait for the next monthly release" rule, it will be fixed in the most
> recent bugfix tock.
>
> will tick-tock completely replace that "traditional"
> > section?
>
>
> Yes.
>
>
> > In which case, the question of criteria for defining "stable
> > release" remains, unless it becomes no different than the latest
> tick-tock
> > release.
> >
>
> That's the idea, and that's why we're getting very religious about test
> engineering, so that those monthly releases will always be stable.
>
Re: Versioning policy?
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Jan 14, 2016 at 4:26 PM, Jack Krupansky <ja...@gmail.com>
wrote:
> Jonathan, just to complete the list, it would be help to state:
>
> 3.1.x will be maintained until <what>
> 3.2 will be maintained until <what>
>
One of the confusing things about tick tock is that we're stuck with
numbers that look like the old ones but mean different things.
In the old world, 2.1 was a release that took a year of work, and it got
maintained with roughly-monthly updates of 2.1.x.
In the tick tock world, the corresponding series is just "3," and the
monthly updates are 3.1, 3.2, and so forth, with new features allowed in
the even releases every two months. So in general, there will be no 3.1.x
or 3.2.y releases. When a bug is critical enough to make an exception to
the "wait for the next monthly release" rule, it will be fixed in the most
recent bugfix tock.
will tick-tock completely replace that "traditional"
> section?
Yes.
> In which case, the question of criteria for defining "stable
> release" remains, unless it becomes no different than the latest tick-tock
> release.
>
That's the idea, and that's why we're getting very religious about test
engineering, so that those monthly releases will always be stable.
Re: Versioning policy?
Posted by Jack Krupansky <ja...@gmail.com>.
Jonathan, just to complete the list, it would be help to state:
3.1.x will be maintained until <what>
3.2 will be maintained until <what>
And in general, 3.x (x != 0) will be maintained until <what> (and does x
even vs. odd affect the rule)
And what exactly is the general rule/criteria for when 3.x will be
considered the official "stable release"? And will 3.0.x always be
considered the recommended non-production release until 4.0 comes out or is
there general guidance/criteria for when a 3.x would become recommended for
non-production? Or will tick-tock completely replace that "traditional"
section? In which case, the question of criteria for defining "stable
release" remains, unless it becomes no different than the latest tick-tock
release.
-- Jack Krupansky
On Thu, Jan 14, 2016 at 12:57 PM, Anuj Wadehra <an...@yahoo.co.in>
wrote:
> Hi Jonathan,
> Thanks for the crisp communication regarding the tick tock release & EOL.
> I think its worth considering some points regarding EOL policy and it
> would be great if you can share your thoughts on below points:
> 1. EOL of a release should be based on "most stable"/"production ready"
> version date rather than "GA" date of subsequent major releases.
> 2. I think we should have "Formal EOL Announcement" on Apache Cassandra
> website.
> 3. "Formal EOL Announcement" should come at least 6 months before the EOL,
> so that users get reasonable time to upgrade.
> 4. EOL Policy (even if flexible) should be stated on Apache Cassandra
> website
>
> EOL thread on users mailing list ended with the conclusion of raising a
> Wishlist JIRA but I think above points are more about working on policy and
> processes rather than just a wish list.
>
> ThanksAnuj
>
>
>
> Sent from Yahoo Mail on Android
>
> On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis<jb...@gmail.com>
> wrote: Hi Maciek,
>
> First let's talk about the tick-tock series, currently 3.x. This is pretty
> simple: outside of the regular monthly releases, we will release fixes for
> critical bugs against the most recent bugfix release, the way we did
> recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases
> will be patched.
>
> Now, we also have three other release series currently being supported:
>
> 2.1.x: supported with critical fixes only until 4.0 is released, projected
> in November 2016 [2]
> 2.2.x: maintained until 4.0 is released
> 3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
>
> I will add this information to the releases page [3].
>
> [1]
>
> https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690PZpozA@mail.gmail.com%3E
> [2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
> sunsetting deprecated features like Thrift so bumping the major version
> seems appropriate
> [3] http://cassandra.apache.org/download/
>
> On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda <ma...@heroku.com>
> wrote:
>
> > There was a discussion recently about changing the Cassandra EOL policy
> on
> > the users list [1], but it didn't really go anywhere. I wanted to ask
> here
> > instead to clear up the status quo first. What's the current versioning
> > policy? The tick-tock versioning blog post [2] states in passing that two
> > major releases are maintained, but I have not found this as an official
> > policy stated anywhere. For comparison, the Postgres project lays this
> out
> > very clearly [3]. To be clear, I'm not looking for any official support,
> > I'm just asking for clarification regarding the maintenance policy: if a
> > critical bug or security vulnerability is found in version X.Y.Z, when
> can
> > I expect it to be fixed in a bugfix patch to that major version, and when
> > do I need to upgrade to the next major version.
> >
> > [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
> > [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
> > [3]: http://www.postgresql.org/support/versioning/
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
>
Re: Versioning policy?
Posted by Anuj Wadehra <an...@yahoo.co.in>.
Hi Jonathan,
Thanks for the crisp communication regarding the tick tock release & EOL.
I think its worth considering some points regarding EOL policy and it would be great if you can share your thoughts on below points:
1. EOL of a release should be based on "most stable"/"production ready" version date rather than "GA" date of subsequent major releases.
2. I think we should have "Formal EOL Announcement" on Apache Cassandra website.
3. "Formal EOL Announcement" should come at least 6 months before the EOL, so that users get reasonable time to upgrade.
4. EOL Policy (even if flexible) should be stated on Apache Cassandra website
EOL thread on users mailing list ended with the conclusion of raising a Wishlist JIRA but I think above points are more about working on policy and processes rather than just a wish list.
ThanksAnuj
Sent from Yahoo Mail on Android
On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis<jb...@gmail.com> wrote: Hi Maciek,
First let's talk about the tick-tock series, currently 3.x. This is pretty
simple: outside of the regular monthly releases, we will release fixes for
critical bugs against the most recent bugfix release, the way we did
recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases
will be patched.
Now, we also have three other release series currently being supported:
2.1.x: supported with critical fixes only until 4.0 is released, projected
in November 2016 [2]
2.2.x: maintained until 4.0 is released
3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
I will add this information to the releases page [3].
[1]
https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690PZpozA@mail.gmail.com%3E
[2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
sunsetting deprecated features like Thrift so bumping the major version
seems appropriate
[3] http://cassandra.apache.org/download/
On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda <ma...@heroku.com> wrote:
> There was a discussion recently about changing the Cassandra EOL policy on
> the users list [1], but it didn't really go anywhere. I wanted to ask here
> instead to clear up the status quo first. What's the current versioning
> policy? The tick-tock versioning blog post [2] states in passing that two
> major releases are maintained, but I have not found this as an official
> policy stated anywhere. For comparison, the Postgres project lays this out
> very clearly [3]. To be clear, I'm not looking for any official support,
> I'm just asking for clarification regarding the maintenance policy: if a
> critical bug or security vulnerability is found in version X.Y.Z, when can
> I expect it to be fixed in a bugfix patch to that major version, and when
> do I need to upgrade to the next major version.
>
> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
> [3]: http://www.postgresql.org/support/versioning/
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Versioning policy?
Posted by Jonathan Ellis <jb...@gmail.com>.
Hi Maciek,
First let's talk about the tick-tock series, currently 3.x. This is pretty
simple: outside of the regular monthly releases, we will release fixes for
critical bugs against the most recent bugfix release, the way we did
recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases
will be patched.
Now, we also have three other release series currently being supported:
2.1.x: supported with critical fixes only until 4.0 is released, projected
in November 2016 [2]
2.2.x: maintained until 4.0 is released
3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
I will add this information to the releases page [3].
[1]
https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690PZpozA@mail.gmail.com%3E
[2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
sunsetting deprecated features like Thrift so bumping the major version
seems appropriate
[3] http://cassandra.apache.org/download/
On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda <ma...@heroku.com> wrote:
> There was a discussion recently about changing the Cassandra EOL policy on
> the users list [1], but it didn't really go anywhere. I wanted to ask here
> instead to clear up the status quo first. What's the current versioning
> policy? The tick-tock versioning blog post [2] states in passing that two
> major releases are maintained, but I have not found this as an official
> policy stated anywhere. For comparison, the Postgres project lays this out
> very clearly [3]. To be clear, I'm not looking for any official support,
> I'm just asking for clarification regarding the maintenance policy: if a
> critical bug or security vulnerability is found in version X.Y.Z, when can
> I expect it to be fixed in a bugfix patch to that major version, and when
> do I need to upgrade to the next major version.
>
> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
> [3]: http://www.postgresql.org/support/versioning/
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced