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=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-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
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>
