Re: Versioning policy?
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 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 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 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-=v690pzp...@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 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?
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 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 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 >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 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-=v690pzp...@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 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?
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 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 > 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 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-=v690pzp...@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 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?
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 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 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-=v690pzp...@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 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?
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 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 wrote: > > > On Thu, Jan 14, 2016 at 4:26 PM, Jack Krupansky < > jack.krupan...@gmail.com> > > wrote: > > > > > Jonathan, just to complete the list, it would be help to state: > > > > > > 3.1.x will be maintained until > > > 3.2 will be maintained until > > > > > > > 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?
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 wrote: > On Thu, Jan 14, 2016 at 4:26 PM, Jack Krupansky > wrote: > > > Jonathan, just to complete the list, it would be help to state: > > > > 3.1.x will be maintained until > > 3.2 will be maintained until > > > > 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?
On Thu, Jan 14, 2016 at 4:26 PM, Jack Krupansky wrote: > Jonathan, just to complete the list, it would be help to state: > > 3.1.x will be maintained until > 3.2 will be maintained until > 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?
Jonathan, just to complete the list, it would be help to state: 3.1.x will be maintained until 3.2 will be maintained until And in general, 3.x (x != 0) will be maintained until (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 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 > 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-=v690pzp...@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 > 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?
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 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-=v690pzp...@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 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?
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-=v690pzp...@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 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?
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 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 > 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?
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 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?
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.