Re: Proposal - 3.5.1

2016-10-20 Thread Jonathan Haddad
>From a community perspective a supported release every 6 months would be much more attractive than yearly, as having to wait ~9-10 months for something like SASI is kind of frustrating. Monthly dev releases is awesome. On Thu, Oct 20, 2016 at 3:18 PM Nate McCall wrote: > >

Re: Proposal - 3.5.1

2016-10-20 Thread Jonathan Haddad
And +1 to ditching the "tick tock" alternating release thing nobody understands it anyway. On Thu, Oct 20, 2016 at 3:38 PM Jonathan Haddad wrote: > From a community perspective a supported release every 6 months would be > much more attractive than yearly, as having to wait

Re: Proposal - 3.5.1

2016-10-20 Thread Nate McCall
> I’m not sure it makes sense to have separate features/stability releases in > that world. 4.0.x will be stable, every 4.x will be a dev release on the road > to 5.0. > +1. Much easier to understand and it's 'backwards compatible' (sort of) with wherever we leave 3.x. Still keeping 4.x on

Re: Proposal - 3.5.1

2016-10-20 Thread Aleksey Yeschenko
I’m not sure it makes sense to have separate features/stability releases in that world. 4.0.x will be stable, every 4.x will be a dev release on the road to 5.0. --  AY On 20 October 2016 at 22:43:19, Jeff Jirsa (jji...@apache.org) wrote: On 2016-10-20 14:21 (-0700), Jeremiah Jordan

Re: Proposal - 3.5.1

2016-10-20 Thread Jeremiah D Jordan
My thinking was we keep doing tick/tock for the 4.x. Basically continue on for 4.0.x / 4.x like we have been with 3.0.x / 3.x, just with some added guidance to people that 4.x is “development releases”. The main problem I hear with the tick tock stuff is that we won’t ever have “LTS” branches

Re: Proposal - 3.5.1

2016-10-20 Thread Jeff Jirsa
On 2016-10-20 14:21 (-0700), Jeremiah Jordan wrote: > In the original tick tock plan we would not have kept 4.0.x around. So I am > proposing a change for that and then we label the 3.x and 4.x releases as > "development releases" or some other thing and have "yearly"

Re: Proposal - 3.5.1

2016-10-20 Thread Jeremiah Jordan
In the original tick tock plan we would not have kept 4.0.x around. So I am proposing a change for that and then we label the 3.x and 4.x releases as "development releases" or some other thing and have "yearly" LTS releases with .0.x. Those are similar to the previous 1.2/2.0/2.1/2.2 and we

Re: Proposal - 3.5.1

2016-10-20 Thread Jeff Jirsa
On 2016-10-20 13:26 (-0700), "J. D. Jordan" wrote: > 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

Re: Proposal - 3.5.1

2016-10-20 Thread J. D. Jordan
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

Re: Proposal - 3.5.1

2016-10-20 Thread Ben Bromhead
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

Re: Proposal - 3.5.1

2016-09-26 Thread Michael Shuler
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

Re: Proposal - 3.5.1

2016-09-20 Thread Jonathan Haddad
@Sylvain - I see what you're saying now on the branches. I suppose a branching strategy like that does give some flexibility to have multiple things in the pipeline so it does give some additional flexibility there. On Mon, Sep 19, 2016 at 9:06 AM Eric Evans wrote:

Re: Proposal - 3.5.1

2016-09-19 Thread Eric Evans
On Fri, Sep 16, 2016 at 5:05 AM, Sylvain Lebresne wrote: > In light of all this, my suggesting for a release cycle woud be: > - To have 3 branches: 'features', 'testing' and 'stable', with an X month > rotation: 'features' becomes 'testing' after X months and then 'stable'

Re: Proposal - 3.5.1

2016-09-19 Thread Eric Evans
On Thu, Sep 15, 2016 at 9:33 PM, Mick Semb Wever wrote: > - keep bimonthly feature releases, > - revert from tick-tock to SemVer numbering scheme, > - during the release vote also vote on the quality label (feature branches > start with a 'Alpha' and the first patch

Re: Proposal - 3.5.1

2016-09-16 Thread Edward Capriolo
If you all have never seen the movie "grandma's boy" I suggest it. https://www.youtube.com/watch?v=uJLQ5DHmw-U There is one funny seen where the product/project person says something like, "The game is ready. We have fixed ALL THE BUGS". The people who made the movie probably think the coders

Re: Proposal - 3.5.1

2016-09-16 Thread Sylvain Lebresne
On Fri, Sep 16, 2016 at 6:59 PM, Blake Eggleston wrote: > Clearly, we won’t get to this point right away, but it should definitely > be a goal. > I'm not entirely clear on why anyone would read in what I'm saying that it shouldn't be a goal. I'm a huge proponent of this

Re: Proposal - 3.5.1

2016-09-16 Thread Jonathan Haddad
Yep - the progress that's been made on trunk recently has been excellent and should continue. The spirit of tick tock - stable trunk - should not change, just that the release cycle did not support what humans are comfortable with maintaining or deploying. On Fri, Sep 16, 2016 at 10:08 AM

Re: Proposal - 3.5.1

2016-09-16 Thread Jonathan Ellis
On Fri, Sep 16, 2016 at 11:36 AM, Jonathan Haddad wrote: > What I was trying to suggest is that the *goal* of trunk should always be > releasable, and the alpha releases would be the means of testing that. If > the goal is to always be releasable, we move towards achieving

Re: Proposal - 3.5.1

2016-09-16 Thread Blake Eggleston
 I'm not even sure it's reasonable to  expect from *any* software, and even less so for an open-source  project based on volunteering. Not saying it wouldn't be amazing, it  would, I just don't believe it's realistic. Postgres does a pretty good job of this. This sort of thinking is a self

Re: Proposal - 3.5.1

2016-09-16 Thread Jonathan Haddad
What I was trying to suggest is that the *goal* of trunk should always be releasable, and the alpha releases would be the means of testing that. If the goal is to always be releasable, we move towards achieving that goal by improving modularity, test coverage and test granularity. Yes, it's very

Re: Proposal - 3.5.1

2016-09-16 Thread Sylvain Lebresne
On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad wrote: > > This is a different mentality from having a "features" branch, where it's > implied that at times it's acceptable that it not be stable. I absolutely never implied that, though I willingly admit my choice of branch

Re: Proposal - 3.5.1

2016-09-16 Thread Jonathan Ellis
On Fri, Sep 16, 2016 at 10:18 AM, Jonathan Haddad wrote: > TL;DR: > Release every 3 months > Support for 6 > Keep a stable trunk > New features get merged into trunk but the standard for code quality and > testing needs to be property defined as something closer to

Re: Proposal - 3.5.1

2016-09-16 Thread Edward Capriolo
"The historical trend with the Cassandra codebase has been to test minimally, throw the code over the wall, and get feedback from people putting it in prod who run into issues." At the summit Brandon and a couple others were making fun over range tombstones from thrift

Re: Proposal - 3.5.1

2016-09-16 Thread Jonathan Haddad
I've worked on a few projects where we've had a branch that new stuff went in before merging to master / trunk. What you've described reminds me a lot of git-flow (http://nvie.com/posts/a-successful-git-branching-model/) although not quite the same. I'll be verbose in this email to minimize the

Re: Proposal - 3.5.1

2016-09-16 Thread Sylvain Lebresne
As probably pretty much everyone at this point, I agree the tick-tock experiment isn't working as well as it should and that it's probably worth course correcting. I happen to have been thinking about this quite a bit already as it turns out so I'm going to share my reasoning and suggestion below,

Re: Proposal - 3.5.1

2016-09-15 Thread Mick Semb Wever
Totally agree with all the frustrations felt by Jon here. TL;DR Here's a proposal for 4.0 and beyond: that is puts together the comments from Benedict, Jon, Tyler, Jeremy, and Ed; - keep bimonthly feature releases, - revert from tick-tock to SemVer numbering scheme, - during the release vote

Re: Proposal - 3.5.1

2016-09-15 Thread Jonathan Haddad
If the releases can be tagged as alpha / beta so that people don't accidentally put it in prod (or at least, will do so less), that would be totally reasonable. On Thu, Sep 15, 2016 at 12:27 PM Tyler Hobbs wrote: > On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith < >

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
Yes, agreed. I'm advocating a different cadence, not a random cadence. On Thursday, 15 September 2016, Tyler Hobbs wrote: > On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith < > bened...@apache.org > > wrote: > > > Feature releases don't have to be on

Re: Proposal - 3.5.1

2016-09-15 Thread Tyler Hobbs
On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith wrote: > Feature releases don't have to be on the same cadence as bug fixes. They're > naturally different beasts. > With the exception of critical bug fixes (which can warrant an immediate release), I think keeping a

Re: Proposal - 3.5.1

2016-09-15 Thread Tyler Hobbs
I agree that regular (monthly) releases, and smaller, more frequent feature releases are the best part of tick/tock. The downside of tick/tock, as mentioned above, is that there isn't enough time for user feedback and testing to catch new bugs before the next feature release. I would personally

Re: Proposal - 3.5.1

2016-09-15 Thread Jeremy Hanna
Right - I think like Jake and others have said, it seems appropriate to do something at this point. Would a clearer, more liberal backport policy to the odd versions be worthwhile until we find our footing? As Jeremiah said, it does seem like the big bang 3.0 release has caused much of the

Re: Proposal - 3.5.1

2016-09-15 Thread Jonathan Haddad
I don't think it's binary - we don't have to do year long insanity or bleeding edge crazyness. How about a release every 3 months, with each release accepting 6 months of patches? (oldstable & newstable) Also provide nightly builds & stick to the idea of stable trunk. The issue is the number

Re: Proposal - 3.5.1

2016-09-15 Thread Jeremiah D Jordan
Because tick-tock started based off of the 3.0 big bang “we broke everything” release I don’t think we can judge wether or not it is working until we are another 6 months in. AKA when we would have been releasing the next big bang release. Right now a lot if not most of the bugs in a given

Re: Proposal - 3.5.1

2016-09-15 Thread Jake Luciani
I'm pretty sure everyone will agree Tick-Tock didn't go well and needs to change. The problem for me is going back to the old way doesn't sound great. There are parts of tick-tock I really like, for example, the cadence and limited scope per release. I know at the summit there were a lot of

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
I agree tick-tock is a failure. But for two reasons IMO: 1) Ultimately, the users are the real testers and it takes a while for a release to percolate into the wild for feedback. The reality is that a release doesn't have its tires properly kicked for at least three months after it's cut. So

Re: Proposal - 3.5.1

2016-09-15 Thread Jeff Jirsa
I know we’ve got a lot of folks following the dev list without a lot of background, so let’s make sure we get some context here so everyone can be on the same page. Going to preface this wall of text by saying I’m +1 on a 3.5.1 (and 3.3.1, etc) if it’s done AFTER 3.9 (I think we need to get

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
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

Re: Proposal - 3.5.1

2016-09-15 Thread Edward Capriolo
Where did we come from? We came from a place where we would say, "You probably do not want to run 2.0.X until it reaches 2.0.6" One thing about Cassandra is we get into a situation where we can only go forward. For example, when you update from version X to version Y, version Y might start

Re: Proposal - 3.5.1

2016-09-15 Thread Jeremiah D Jordan
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

Re: Proposal - 3.5.1

2016-09-15 Thread Jonathan Haddad
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

Re: Proposal - 3.5.1

2016-09-14 Thread Jeff Jirsa
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

Re: Proposal - 3.5.1

2016-09-14 Thread Jonathan Haddad
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 cassandra.apache.org suggests it's acceptable

Re: Proposal - 3.5.1

2016-09-14 Thread Michael Shuler
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