If you think of the tick tock releases as interim development releases I actually think they have been working pretty well. What if we continue with the same process and do 4.0.x as LTS like we have 3.0.x LTS.
So you get 4.x releases that are trickling out new features which will eventually be in the 5.0.x LTS and you get 4.0.x as an LTS release of all the 3.x built up features. This seems like a fairly straight forward process to me. It gives people monthly releases that they can test new features with, but it also provides a stable line for those that want one. -Jeremiah > On Oct 20, 2016, at 11:57 AM, Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote: > > Thanks Ben. It’s great to have a 3.x LTS option as things work themselves > out. I just wanted to revive this thread in parallel so that it could > hopefully come to a way forward for the project as well. Is the 3 branch > strategy that Sylvain proposed the way forward? > >> On Oct 20, 2016, at 11:52 AM, Ben Bromhead <b...@instaclustr.com> wrote: >> >> For reference we have released https://github.com/instaclustr/cassandra , >> with the end goal that people have a stable target on the 3.x branch while >> this is all worked out. >> >> We are likely to continue our releases even with a release cadence change, >> but we would track official versions much more closely and our repository >> will end up just being a public view of what we do internally rather than >> something we advocate over official releases. >> >> For further details on our thoughts around this see: >> >> - https://www.instaclustr.com/blog/2016/10/19/patched-cassandra-3-7/ >> - https://github.com/instaclustr/cassandra#faq >> >> >> On Thu, 20 Oct 2016 at 09:38 Jeremy Hanna <jeremy.hanna1...@gmail.com> >> wrote: >> >>> Is there consensus on a way forward with this? Is there going to be a >>> three branch plan with “features”, “testing”, and “stable” starting with >>> 4.0? Or is this still in the discussion mode? External to this thread >>> there have been decisions made to create third party LTS releases and hopes >>> that the project would decide to address the concerns in this thread. It >>> seems like this is the place to complete the discussion. >>> >>>> On Sep 26, 2016, at 10:52 AM, Jonathan Haddad <j...@jonhaddad.com> wrote: >>>> >>>> Not yet. I hadn't seen any Jirsa before to release a specific version, >>> only >>>> discussion on the ML. >>>> >>>> I'll put up a Jira with my patch that back ports the bug fix. >>>> On Mon, Sep 26, 2016 at 8:26 AM Michael Shuler <mich...@pbandjelly.org> >>>> wrote: >>>> >>>>> Jon, is there a JIRA ticket for this request? I appreciate everyone's >>>>> input, and I think this is a fine proposal. >>>>> >>>>> -- >>>>> Kind regards, >>>>> 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://github.com/rustyrazorblade/cassandra/tree/fix_commitlog_exception >>>>>> >>>>>> Jon >>>>>> >>>>> >>>>> >>> >>> -- >> Ben Bromhead >> CTO | Instaclustr <https://www.instaclustr.com/> >> +1 650 284 9692 >> Managed Cassandra / Spark on AWS, Azure and Softlayer >
