The old "most stable" labeling was super-important in the old days since newer releases tended to have a fair amount of instability - hence the admonition to wait for a x.y.5 release before using the x.y release line. But that dramatic degree of release instability is no longer the case. Besides, we already have 3.5 and 3.0.5, so that x.y.5 point is now moot. And, generally, there won't be any 3.x.y releases other than 3.0.y and 3.x.0 unless something especially unusual goes wrong - there have only been two, 3.1.1 and 3.2.1.
The simple fact that there have only been five subsequent patch releases for 3.0.0 in over five months is a testament to its stability. That's not an argument for why anybody should switch from 2.x to 3.x if 2.x is working fine for them, but a challenge to the presumption that 3.x is unstable and unsuitable for production. To put it more simply, the goal is that no 3.x (or x.y for x > 2) goes out the door unless it is suitable for production. To put it even more strongly, I think the development and release process is now robust enough that no new releases, 2.x or 3.x, get out the door unless suitable for production. In short, the only reason to go with 2.2.x at this stage is if you are currently using 2.2.x and simply don't want to rock the boat in even the smallest way. That's reasonable. But if you are using 2.1.x or earlier and feel the need to upgrade due to EOL or whatever, in may be less risky to complete the full upgrade path to 3.x rather than go halfway since sometimes halfhearted measures don't get the degree of attention needed for the full effort, such as people trying to cut corners to do it on the cheap. -- Jack Krupansky On Sat, Apr 23, 2016 at 10:50 PM, Anuj Wadehra < anujw_2...@yahoo.co.in.invalid> wrote: > Jack, > The question was about publishing "most stable" release on Apache website > as it done before 3.x. > Regarding your comments, I still feel adventure cant happen in production > systems. And you should certainly test every release before upgrading but > you woulf not like to upgrade to latest releases based on your limited > testing. I feel that you cant do exhaustive testing of the database and can > easily miss critical corner cases which may trigger in production. But its > just my perspective of looking at things. People may think differently. > Thanks All of you for your comments !! > > ThanksAnuj > Sent from Yahoo Mail on Android > > On Sun, 24 Apr, 2016 at 1:28 AM, Jack Krupansky<jack.krupan...@gmail.com> > wrote: Is the question whether a new application can go into production > with 3.x, > or whether an existing application in production with 2.x.y should be > upgraded to 3.x? > > For the latter, a "If it ain't broke, don't fix it" philosophy is best. And > if there are critical bug fixes needed, simply upgrade the 2.x line that > you are already on. Or if your production is on 3.0.x, upgrade to 3.0.x+k. > > For the former, we aren't hearing people hollering that 3.x is crap, so it > is reasonably safe for a new app going into production, subject to your own > testing. > > Given the relative stability of 3.x due to the tick-tock and "trunk always > releasable" strategies, users are no longer faced with the kind of wild > instabilities of the past. > > Ultimately, stability really is subjective and in the eye of the beholder - > how conservative or adventurous are you and your organization. Sure, maybe > 2.2.x is more stable in some abstract sense, but for a new app, why start > so far behind the curve? In fact, for a new app you should be trying to > take advantage of new features and performance improvements, like > materialized views, SASI, and wide rows coming soon. > > In the past, upgrading from 2.x to 2.y was a big deal. That just isn't a > problem with upgrading from 3.x to 3.y. At least in theory, and again, > nobody has been hollering about having problems doing that. > > For EOL, you will have to judge for yourself how long it may take your > organization to carefully migrate a production 2.x system to 3.x somewhere > down the road. No need to rush, but don't wait until the last minute > either. And I suspect that you won't even want to think about upgrading 2.x > to 4.x - IOW, upgrade to 3.x well before 3.x EOL. > > -- Jack Krupansky > > On Sat, Apr 23, 2016 at 3:28 PM, Anuj Wadehra < > anujw_2...@yahoo.co.in.invalid> wrote: > > > Jonathan, > > I understand you point. In my perspective, people in production usually > > prefer stability over features and would always want at least emergency > fix > > releases if not fully supported versions.I am glad that today we have > such > > releases which are very stable and not yet EOL. Its just that users are > > tempted to use latest odd releases as per the tick-tock strategy > > highlighted on the website and then probably fallback to previous ones > > after discussing stable versions on various forums. I just wanted to make > > their decisions simpler :) I agree with you - Every thing cant be white > and > > black..stable and unstable..At the same..I feel.. most of the time there > > would be a single stable release which is not EOL. > > Thanks for your time. > > > > > > Anuj > > Sent from Yahoo Mail on Android > > > > On Tue, 19 Apr, 2016 at 7:06 AM, Jonathan Ellis<jbel...@gmail.com> > > wrote: Anuj, > > > > The problem is that this question defies a simplistic answer like > "version > > X is the most stable" (are you willing to use unsupported releases? what > > about emergency-fix-only? what features can you not live without?) so > > we're intentionally resisting the urge to oversimplify the situation. > > > > On Mon, Apr 18, 2016 at 8:25 PM, Anuj Wadehra < > > anujw_2...@yahoo.co.in.invalid> wrote: > > > > > Hi All, > > > Let me reiterate, my question is not about selecting right Cassandra > for > > > me. The intent is to get dev community response on below question. > > > Question: > > > Would it be a wise decision to mention the "most stable/production > > > ready" version (as it used to be before 3.x) on the Apache website till > > > tick-tock release strategy evolves and matures? > > > > > > Drivers for posting above info on website: > > > I have read all the posts/forums and realized that there is no > absolute > > > answer for selecting Production Ready Cassandra version one should > > > use..Even now, people often hesitate to recommend latest releases for > > Prod > > > and go back to 2.1 and 2.2..In every suggestion there are too many > > > ifs..like I said...if you want features x..if u want rock solid y..if > you > > > are adventurous z....no offense but who would not want a rock solid > > > version for Production? Who would want features for stability in Prod? > > And > > > who would want to take risks in Prod? > > > The stability of a release should NOT depend my risk appetite and use > > > case..if some version of 2.1 or 2.2 or 3.0.x is stable for production > why > > > not put that info until tick-tock matures? > > > > > > Please realize that everyone goes for thorough testing before upgrading > > > but the scope of application testing cant uncover most critical > > > bugs..Community guidance and a bigger picture on stability can help the > > > community until tick-tock matures and we deliver stable production > ready > > > releases. > > > > > > > > > > > > ThanksAnuj > > > Sent from Yahoo Mail on Android > > > > > > On Tue, 19 Apr, 2016 at 3:01 AM, Carlos Rolo<r...@pythian.com> wrote: > > > My blog post regarding this: > > > > > > https://www.pythian.com/blog/cassandra-version-production/ > > > > > > There is a choice for everyone, and explained. > > > > > > Regards, > > > > > > Carlos Juzarte Rolo > > > Cassandra Consultant / Datastax Certified Architect / Cassandra MVP > > > > > > Pythian - Love your data > > > > > > rolo@pythian | Twitter: @cjrolo | Linkedin: * > > > linkedin.com/in/carlosjuzarterolo > > > <http://linkedin.com/in/carlosjuzarterolo>* > > > Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649 > > > www.pythian.com > > > > > > On Mon, Apr 18, 2016 at 7:12 PM, Anuj Wadehra < > > > anujw_2...@yahoo.co.in.invalid> wrote: > > > > > > > I am sorry but here, I am not expecting thousands to decide a stable > > > > version for my use case. I have a serious question about publishing > > some > > > > info on the Apache website. As dev list has active contributors, I > > posted > > > > it here. If not this forum, Whats the best way to put your > suggestions > > > > regarding Apache content and initiate a meaningful and conclusive > > > > discussion thread? > > > > > > > > ThanksAnuj > > > > > > > > Sent from Yahoo Mail on Android > > > > > > > > On Mon, 18 Apr, 2016 at 11:27 PM, Michael Kjellman< > > > > mkjell...@internalcircle.com> wrote: This is best for the users > list. > > > > Test the releases yourself and then decide when it's ready for your > use > > > > case, ops team, and organization. This is a personal decision and not > > one > > > > for *thousands* of others on this mailing list to make for you. > > > > > > > > best, > > > > kjellman > > > > > > > > > On Apr 18, 2016, at 10:54 AM, Anuj Wadehra > > > > <anujw_2...@yahoo.co.in.INVALID> wrote: > > > > > > > > > > Hi All, > > > > > For last several months, the "most stable version" question pops up > > on > > > > the user mailing list and then people get all sorts of > > > > responses/suggestions.. > > > > > If you are conservative go for x if adventurous y.. > > > > > If you have good risk appetite go for x else y.. > > > > > If you want features go for x else y.. > > > > > > > > > > Unfortunately, all above responses dont help many users..but only > > > > reinforce the low confidence in latest releases.Who wants to be > > > adventurous > > > > in Production? Who wants to test his risk appetite in Production? And > > who > > > > would want features for stability in Production? Not many..I am sure. > > > > > So my question is: > > > > > Would it be a wise decision to mention the "most stable/production > > > > ready" version (as it used to be before 3.x) on the Apache website > till > > > > tick-tock release strategy evolves and matures? > > > > > That will somewhat contradict the tick-tock philosphy of stable > odd > > > > releases but would be more realistic as every big change needs time > to > > > > stabilise. Its slightly unfair, if users are kept in confused state > > till > > > > the strategy matures and starts delivering solid stable builds. > > > > > I think the question is more appropriate in dev list so I have kept > > it > > > > here. > > > > > ThanksAnuj > > > > > Sent from Yahoo Mail on Android > > > > > > > > > > On Mon, 11 Apr, 2016 at 11:39 PM, Aleksey Yeschenko< > > > alek...@apache.org> > > > > wrote: The answer will depend on how conservative you are. > > > > > > > > > > The most conservative choice overall would be to go with the 2.2.x > > > line. > > > > > > > > > > 3.0.x if you want to the new nice and shiny 3.0 things, but can > > > tolerate > > > > some risk (the branch has a lot of relatively new core code, and > hasn’t > > > yet > > > > been tried out by as many users as the 2.x branch had). > > > > > > > > > > The latest odd 3.x if you want the shiniest (3.5 to be released > soon, > > > > with features like the new SASI secondary indexes support). Also, > there > > > > hasn’t yet been that much divergence between 3.0.x and 3.x, so risk > > > levels > > > > are around the same, so long as you limit yourself to only the > features > > > > present in 3.0.x. > > > > > > > > > > Either way, make sure to properly test whatever release you go for > in > > > > staging first, as Michael says, and you’ll be alright. > > > > > > > > > > -- > > > > > AY > > > > > > > > > > On 11 April 2016 at 18:42:31, Anuj Wadehra > > > > (anujw_2...@yahoo.co.in.invalid) wrote: > > > > > > > > > > Can someone help me with this one? > > > > > ThanksAnuj > > > > > > > > > > Sent from Yahoo Mail on Android > > > > > > > > > > On Sun, 10 Apr, 2016 at 11:07 PM, Anuj Wadehra< > > anujw_2...@yahoo.co.in> > > > > wrote: Hi, > > > > > Tick-Tock release strategy in 3.x was a good intiative to ensure > > > > frequent & stable releases. While odd releases are supposed to get > all > > > the > > > > bug fixes and should be most stable, many people like me, who got > used > > to > > > > the comforting "production ready/stable" tag on Apache website, are > > > still > > > > reluctant to take latest 3.x odd releases into production. I think > the > > > > hesitation is somewhat justified as processes often take time to > > mature. > > > > > So here I would like to ask the experts, people who know the ground > > > > situation, people who actively develop it and manage it. Considering > > the > > > > current scenario, What should be a resonable criteria for taking 3.x > > > > releases in production? > > > > > > > > > > > > > > > ThanksAnuj > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > -- > > > > > > > > > > > > > > > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder, http://www.datastax.com > > @spyced > > >
