+1 on killing tick/tock +1 on six months What is the appetite for a longer bug fix period for some releases (e.g. every second release gets 18 - 24 months critical bug fixes)?
Currently only vendors / large users are maintaining long running releases, given this work is already happening I would rather the effort happen under the Apache umbrella and be available for all user if existing long term release maintainers are happy to do so. If this question is to outside the topic and more appropriate for a different thread I'm happy to put a hold on it until the release cadence is agreed. On Tue, 10 Jan 2017 at 09:27 Nate McCall <zznat...@gmail.com> wrote: > > I agreed with you at the time that the yearly cycle was too long to be > > adding features before cutting a release, and still do now. Instead of > > elastic banding all the way back to a process which wasn't working > before, > > why not try somewhere in the middle? A release every 6 months (with > > monthly bug fixes for a year) gives: > > > > 1. long enough time to stabilize (1 year vs 1 month) > > 2. not so long things sit around untested forever > > 3. only 2 releases (current and previous) to do bug fix support at any > > given time. > > The third reason is particularly appealing. > > +1 on six months. > +1 on killing tick/tock at 3.10 (with a potential bugfix follow up per > the other thread). > -- Ben Bromhead CTO | Instaclustr <https://www.instaclustr.com/> +1 650 284 9692 Managed Cassandra / Spark on AWS, Azure and Softlayer
