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 <anujw_2...@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<jbel...@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-=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 <mac...@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 > >
