It's worth noting more clearly that 3.5 is an arbitrary point in time. All
3.X releases < 3.6 are affected.
If we backport to 3.5, it seems like 3.1 and 3.3 should get the same
treatment. I do recall commitments to backport critical fixes, but exactly
what the bar is was never well defined.
I also cannot see how there would be any added confusion.
On 15 September 2016 at 18:31, Dave Lester <dave_les...@apple.com> wrote:
> How would cutting a 3.5.1 release possibly confuse users of the software?
> It would be easy to document the change and to send release notes.
>
> Given the bug’s critical nature and that it's a minor fix, I’m +1
> (non-binding) to a new release.
>
> Dave
>
> > On Sep 15, 2016, at 7:18 AM, Jeremiah D Jordan <
> jeremiah.jor...@gmail.com> wrote:
> >
> > I’m with Jeff on this, 3.7 (bug fixes on 3.6) has already been released
> with the fix. Since the fix applies cleanly anyone is free to put it on
> top of 3.5 on their own if they like, but I see no reason to put out a
> 3.5.1 right now and confuse people further.
> >
> > -Jeremiah
> >
> >
> >> On Sep 15, 2016, at 9:07 AM, Jonathan Haddad <j...@jonhaddad.com> wrote:
> >>
> >> As I follow up, I suppose I'm only advocating for a fix to the odd
> >> releases. Sadly, Tick Tock versioning is misleading.
> >>
> >> If tick tock were to continue (and I'm very much against how it
> currently
> >> works) the whole even-features odd-fixes thing needs to stop ASAP, all
> it
> >> does it confuse people.
> >>
> >> The follow up to 3.4 (3.5) should have been 3.4.1, following semver, so
> >> people know it's bug fixes only to 3.4.
> >>
> >> Jon
> >>
> >> On Wed, Sep 14, 2016 at 10:37 PM Jonathan Haddad <j...@jonhaddad.com>
> wrote:
> >>
> >>> In this particular case, I'd say adding a bug fix release for every
> >>> version that's affected would be the right thing. The issue is so
> easily
> >>> reproducible and will likely result in massive data loss for anyone on
> 3.X
> >>> WHERE X < 6 and uses the "date" type.
> >>>
> >>> This is how easy it is to reproduce:
> >>>
> >>> 1. Start Cassandra 3.5
> >>> 2. create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> >>> 'replication_factor': 1};
> >>> 3. use test;
> >>> 4. create table fail (id int primary key, d date);
> >>> 5. delete d from fail where id = 1;
> >>> 6. Stop Cassandra
> >>> 7. Start Cassandra
> >>>
> >>> You will get this, and startup will fail:
> >>>
> >>> ERROR 05:32:09 Exiting due to error while processing commit log during
> >>> initialization.
> >>> org.apache.cassandra.db.commitlog.CommitLogReplayer$
> CommitLogReplayException:
> >>> Unexpected error deserializing mutation; saved to
> >>> /var/folders/0l/g2p6cnyd5kx_1wkl83nd3y4r0000gn/T/
> mutation6313332720566971713dat.
> >>> This may be caused by replaying a mutation against a table with the
> same
> >>> name but incompatible schema. Exception follows:
> >>> org.apache.cassandra.serializers.MarshalException: Expected 4 byte
> long for
> >>> date (0)
> >>>
> >>> I mean.. come on. It's an easy fix. It cleanly merges against 3.5
> (and
> >>> probably the other releases) and requires very little investment from
> >>> anyone.
> >>>
> >>>
> >>> On Wed, Sep 14, 2016 at 9:40 PM Jeff Jirsa <jeff.ji...@crowdstrike.com
> >
> >>> wrote:
> >>>
> >>>> We did 3.1.1 and 3.2.1, so there’s SOME precedent for emergency fixes,
> >>>> but we certainly didn’t/won’t go back and cut new releases from every
> >>>> branch for every critical bug in future releases, so I think we need
> to
> >>>> draw the line somewhere. If it’s fixed in 3.7 and 3.0.x (x >= 6), it
> seems
> >>>> like you’ve got options (either stay on the tick and go up to 3.7, or
> bail
> >>>> down to 3.0.x)
> >>>>
> >>>> Perhaps, though, this highlights the fact that tick/tock may not be
> the
> >>>> best option long term. We’ve tried it for a year, perhaps we should
> instead
> >>>> discuss whether or not it should continue, or if there’s another
> process
> >>>> that gives us a better way to get useful patches into versions people
> are
> >>>> willing to run in production.
> >>>>
> >>>>
> >>>>
> >>>> On 9/14/16, 8:55 PM, "Jonathan Haddad" <j...@jonhaddad.com> wrote:
> >>>>
> >>>>> Common sense is what prevents someone from upgrading to yet another
> >>>>> completely unknown version with new features which have probably
> broken
> >>>>> even more stuff that nobody is aware of. The folks I'm helping right
> >>>>> deployed 3.5 when they got started because
> >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__
> cassandra.apache.org&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kq
> hAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
> MZ9nLcNNhQZkuXyH0NBbP1kSEE2M-SYgyVqZ88IJcXY&s=pLP3udocOcAG6k_
> sAb9p8tcAhtOhpFm6JB7owGhPQEs&e=
> >>>> suggests
> >>>>> it's acceptable for production. It turns out using 4 of the built in
> >>>>> datatypes of the database result in the server being unable to
> restart
> >>>>> without clearing out the commit logs and running a repair. That
> screams
> >>>>> critical to me. You shouldn't even be able to install 3.5 without
> the
> >>>>> patch I've supplied - that bug is a ticking time bomb for anyone that
> >>>>> installs it.
> >>>>>
> >>>>> On Wed, Sep 14, 2016 at 8:12 PM Michael Shuler <
> mich...@pbandjelly.org>
> >>>>> wrote:
> >>>>>
> >>>>>> What's preventing the use of the 3.6 or 3.7 releases where this bug
> is
> >>>>>> already fixed? This is also fixed in the 3.0.6/7/8 releases.
> >>>>>>
> >>>>>> Michael
> >>>>>>
> >>>>>> On 09/14/2016 08:30 PM, Jonathan Haddad wrote:
> >>>>>>> Unfortunately CASSANDRA-11618 was fixed in 3.6 but was not back
> >>>> ported to
> >>>>>>> 3.5 as well, and it makes Cassandra effectively unusable if someone
> >>>> is
> >>>>>>> using any of the 4 types affected in any of their schema.
> >>>>>>>
> >>>>>>> I have cherry picked & merged the patch back to here and will put
> it
> >>>> in a
> >>>>>>> JIRA as well tonight, I just wanted to get the ball rolling asap on
> >>>> this.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.
> com_rustyrazorblade_cassandra_tree_fix-5Fcommitlog-5Fexception&d=DQIBaQ&c=
> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
> MZ9nLcNNhQZkuXyH0NBbP1kSEE2M-SYgyVqZ88IJcXY&s=ktY5tkT-
> nO1jtyc0EicbgZHXJYl03DvzuxqzyyOgzII&e=
> >>>>>>>
> >>>>>>> Jon
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >
>
>
