Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of rcoli@eventbrite.com designates
 74.125.82.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <b85a6ed8-82f2-4d8c-bf07-8d32b6d0e224@me.com>
References: <b85a6ed8-82f2-4d8c-bf07-8d32b6d0e224@me.com>
Date: Mon, 9 Mar 2015 17:38:47 -0700
Message-ID: 
 <CAEDUwd2CwAJMziDQqUu2Ay+3U0GAw9aM5UrhC6uqjx48FSRzuw@mail.gmail.com>
Subject: Re: What are the reasons for holding off on 2.1.x at this point?
From: Robert Coli <rcoli@eventbrite.com>
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Content-Type: multipart/alternative; boundary=047d7b5d8d9db4c7f10510e45f9a

--047d7b5d8d9db4c7f10510e45f9a
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 9, 2015 at 4:42 PM, Jacob Rhoden <jacob.rhoden@me.com> wrote:

> I notice some of the discussion about rolling back and avoiding upgrading.
> I wonder if people can elaborate on their pain points?
>
> We are in a situation where there are some use cases we wish to implement
> that appear to be much simpler to implement using indexed sets. So it has
> me wondering about what the cons would be of jumping into 2.1.3, instead of
> having to code around the limits of 2.0.x, and then re-write the features
> once we can use 2.1.3. (Ideally we want to get these use cases into prod
> within the next 4 weeks)
>

2.1.1 probably has some serious issue that I'm not recalling right now.

2.1.2 is broken and should not be run in production.

2.1.3 appears to have a memory leak in some circumstances. If you are not
in those circumstances, perhaps that is not prohibitive.

As Graham suggested, I would develop against 2.1.x but not run 2.1.x in
production until at least 2.1.4.

=Rob

--047d7b5d8d9db4c7f10510e45f9a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 9, 2015 at 4:42 PM, Jacob Rhoden <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jacob.rhoden@me.com" target=3D"_blank">jacob.rhoden@me.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div><div>I notice some of the discussion a=
bout rolling back and avoiding upgrading. I wonder if people can elaborate =
on their pain points?=C2=A0</div><div><br></div><div>We are in a situation =
where there are some use cases we wish to implement that appear to be much =
simpler to implement using indexed sets. So it has me wondering about what =
the cons would be of jumping into 2.1.3, instead of having to code around t=
he limits of 2.0.x, and then re-write the features once we can use 2.1.3. (=
Ideally we want to get these use cases into prod within the next 4 weeks)</=
div></div></blockquote><div><br></div><div><div>2.1.1 probably has some ser=
ious issue that I&#39;m not recalling right now.</div></div><div><br></div>=
<div>2.1.2 is broken and should not be run in production.</div><div><br></d=
iv><div>2.1.3 appears to have a memory leak in some circumstances. If you a=
re not in those circumstances, perhaps that is not prohibitive.</div><div><=
br></div><div>As Graham suggested, I would develop against 2.1.x but not ru=
n 2.1.x in production until at least 2.1.4.</div><div><br></div><div>=3DRob=
</div><div>=C2=A0</div></div></div></div>

--047d7b5d8d9db4c7f10510e45f9a--