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 > > > > > > > > > > > > > -- --
