You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cassandra.apache.org by Anuj Wadehra <an...@yahoo.co.in.INVALID> on 2016/04/10 19:37:11 UTC

Criteria for upgrading to 3.x releases in PROD

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

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Jack Krupansky <ja...@gmail.com>.

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_2003@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<ja...@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_2003@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<jb...@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_2003@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<ro...@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_2003@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<
> > > > mkjellman@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
> > > > <an...@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<
> > > aleksey@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_2003@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_2003@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
> >
>

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Anuj Wadehra <an...@yahoo.co.in.INVALID>.

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<ja...@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_2003@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<jb...@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_2003@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<ro...@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_2003@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<
> > > mkjellman@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
> > > <an...@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<
> > aleksey@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_2003@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_2003@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
>

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Jack Krupansky <ja...@gmail.com>.

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_2003@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<jb...@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_2003@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<ro...@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_2003@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<
> > > mkjellman@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
> > > <an...@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<
> > aleksey@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_2003@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_2003@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
>

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Anuj Wadehra <an...@yahoo.co.in.INVALID>.

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<jb...@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_2003@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<ro...@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_2003@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<
> > mkjellman@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
> > <an...@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<
> aleksey@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_2003@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<an...@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

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Jonathan Ellis <jb...@gmail.com>.

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_2003@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<ro...@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_2003@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<
> > mkjellman@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
> > <an...@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<
> aleksey@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_2003@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<an...@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

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Anuj Wadehra <an...@yahoo.co.in.INVALID>.

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<ro...@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_2003@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<
> mkjellman@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
> <an...@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<al...@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_2003@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<an...@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
> >
> >
> >
> >
> >
>
>
>

-- 


--

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Carlos Rolo <ro...@pythian.com>.

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_2003@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<
> mkjellman@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
> <an...@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<al...@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_2003@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<an...@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
> >
> >
> >
> >
> >
>
>
>

-- 


--

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Anuj Wadehra <an...@yahoo.co.in.INVALID>.

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<mk...@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 <an...@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<al...@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_2003@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<an...@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  
> 
> 
> 
> 
>

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Michael Kjellman <mk...@internalcircle.com>.

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 <an...@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<al...@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_2003@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<an...@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  
> 
> 
> 
> 
>

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Anuj Wadehra <an...@yahoo.co.in.INVALID>.

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<al...@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_2003@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<an...@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

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Aleksey Yeschenko <al...@apache.org>.

The answer will depend on how conservative you are.

The most conservative choice overall would be to go with the 2.2.x line.

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_2003@yahoo.co.in.invalid) wrote:

Can someone help me with this one?
ThanksAnuj

Sent from Yahoo Mail on Android

ThanksAnuj

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Michael Shuler <mi...@pbandjelly.org>.

On 04/11/2016 12:42 PM, Anuj Wadehra wrote:
> Can someone help me with this one?

This is the type of question you should ask the user@ list. The dev@
list is specifically for the development *of* Cassandra.

> What should be a resonable criteria for taking 3.x releases in
> production?

Short answer: it works properly for your application and your
dev/test/staging evaluations show no regression. This is true for any
version upgrade.

-- 
Kind regards,
Michael

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Jeff Jirsa <je...@crowdstrike.com>.

As an operator, I’d imagine it’s mostly the same as always - stability will vary by workload, so test with your workload until you’re confident.

If x.y.Z where Z >= 6 was basically the guideline most people used before, then it’s probably worth considering 3.5 and 3.7 as worth testing in your specific environment.

On 4/11/16, 10:42 AM, "Anuj Wadehra" <an...@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<an...@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
>
>
>
>
>

Re: Criteria for upgrading to 3.x releases in PROD

Posted by Anuj Wadehra <an...@yahoo.co.in.INVALID>.

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<an...@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