Re: Wrapping up tick-tock

Unfortunately it's hard to find a definition for "stable" in context of new Cassandra releases. It depends a lot on used features and use cases. New features will likely contain bugs, while the core features should remain stable if there hasn't been a major rewrite or refactoring like in 3.0. If

Re: Wrapping up tick-tock

+1 semver and what anuj says It is commonly known and used, many people know and understand it. Standards for the win! 2017-01-14 19:07 GMT+01:00 Anuj Wadehra : > Hi, > Now that we are rethinking versioning and release frequency, there exists > an opportunity to

Re: Wrapping up tick-tock

Hi, Now that we are rethinking versioning and release frequency, there exists an opportunity to make life easier for Cassandra users. How often mailing lists are discussing: "Which Cassandra version is stable for production?"OR"Is x version stable?" Your release version should indicate your

Re: Wrapping up tick-tock

Mick proposed it (semver) in one of the release proposals, and I dropped the ball on sending out the actual "vote on which release plan we want to use" email, because I messed up and got busy. On Fri, Jan 13, 2017 at 11:26 AM, Russell Bradberry wrote: > Has any thought

Re: Wrapping up tick-tock

Has any thought been given to SemVer? http://semver.org/ -Russ On 1/13/17, 1:57 PM, "Jason Brown" wrote: It's fine to limit the minimum time between major releases to six months, but I do not think we should force a major just because n months have passed. I

Re: Wrapping up tick-tock

Based on the rate of change in Tick Tock, I really doubt it'll be a problem. On Fri, Jan 13, 2017 at 11:07 AM sankalp kohli wrote: > + to Jason idea. We should have a minimum of 6 months between a major > version. > > On Fri, Jan 13, 2017 at 10:57 AM, Jason Brown

Re: Wrapping up tick-tock

+ to Jason idea. We should have a minimum of 6 months between a major version. On Fri, Jan 13, 2017 at 10:57 AM, Jason Brown wrote: > It's fine to limit the minimum time between major releases to six months, > but I do not think we should force a major just because n

Re: Wrapping up tick-tock

It's fine to limit the minimum time between major releases to six months, but I do not think we should force a major just because n months have passed. I think we should up the major only when we have significant (possibly breaking) changes/features. It would seem odd to have a 6.0 that's

Re: Wrapping up tick-tock

I honestly don't understand the release cadence discussion. The 3.x branch is far from production ready. Is this really the time to plan the next major feature releases on top of it, instead of focusing to stabilize 3.x first? Who knows how long that would take, even if everyone would exclusively

Re: Wrapping up tick-tock

+1 to 6 months *major* release. I think we still need *minor* release containing bug fixes (or small features maybe?), which I think would make sense to release more frequently, like monthly. So that we won't need to wait for 6 months for bug fixes, or have to maintain a lot of patches

Re: Wrapping up tick-tock

+1 to 6 month release and ending tick/tock On Tue, Jan 10, 2017 at 9:44 AM, Nate McCall wrote: > > > > 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. > > > >

Re: Wrapping up tick-tock

> > 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. > Let's please do put this on another thread. Thanks for bringing it up though as it is important and needs discussion.

Re: Wrapping up tick-tock

+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

Re: Wrapping up tick-tock

> 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 >

Re: Wrapping up tick-tock

I’m thinking put it on the same rails as 2.2.x and 3.0.x. As needed. --  AY On 10 January 2017 at 16:46:25, Josh McKenzie (jmcken...@apache.org) wrote: > > I would also propose we move on to 3.10.x bugfix only releases from now > on, with all new feature development moving to trunk from now

Re: Wrapping up tick-tock

> > I would also propose we move on to 3.10.x bugfix only releases from now > on, with all new feature development moving to trunk from now on. You thinking monthly release on that or "as needed"? In theory, monthly should be easier than previous tick-tock if we're only putting in bugfix or

Re: Wrapping up tick-tock

6 months seems reasonable to me as well. There seems to be an agreement to halting 3.X on 3.10. I would also propose we move on to 3.10.x bugfix only releases from now on, with all new feature development moving to trunk from now on. This should allow us to finally stabilise 3.X so that we can

Re: Wrapping up tick-tock

+1 to 6 months. On Tue, Jan 10, 2017 at 11:32 AM, Jonathan Ellis wrote: > I agree that 6 month seems like a reasonable compromise. > > On Tue, Jan 10, 2017 at 10:31 AM, Blake Eggleston > wrote: > > > I agree that 3.10 should be the last tick-tock

Re: Wrapping up tick-tock

I agree that 6 month seems like a reasonable compromise. On Tue, Jan 10, 2017 at 10:31 AM, Blake Eggleston wrote: > I agree that 3.10 should be the last tick-tock release, but I also agree > with Jon that we shouldn't go back to yearly-ish releases. > > 6 months has come

Re: Wrapping up tick-tock

The problem with long release cycles is that everything goes in. and you have potentially a mish-mash of features, some more done than others, causing instability. Quick releases attempt to fix this issue by keeping the number of commits down to a manageable size. The problem is that that

Re: Wrapping up tick-tock

I agree that 3.10 should be the last tick-tock release, but I also agree with Jon that we shouldn't go back to yearly-ish releases. 6 months has come up several times now as a good cadence for feature releases, and I think it's a good compromise between the competing interests of long term

Re: Wrapping up tick-tock

Hi, With yearly releases trunk is going to be a mess when it comes time to cut a release. Cutting releases is when people start caring whether all the things in the release are in a finished state. It's when the state of CI finally becomes relevant. If we wait a year we are going to accumulate a

Re: Wrapping up tick-tock

I don't see why it has to be one extreme (yearly) or another (monthly). When you had originally proposed Tick Tock, you wrote: "The primary goal is to improve release quality. Our current major “dot zero” releases require another five or six months to make them stable enough for production.