>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:
> > I’m not sure it make
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 ~9-10 months for
> so
> 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 month
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 wrote:
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
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" LTS releases
> with .0
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 are
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 LTS.
>
> So you get 4.x releas
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
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
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 clo
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
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
wrote:
> Jon, is there a JIRA ticket for this request? I appreciate everyone's
> input, a
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 Cassan
@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:
> On Fri, Sep 16, 2016 at 5:
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'
> after
> X more, be
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 release as 'Beta'),
> - acc
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 doi
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 and of putting emphasis
o
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 Jonatha
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 that goal by
> improvi
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
fulfil
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
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
names may be to blam
Sorry, in my TL;DR I forgot release frequent alphas (nightly / weekly /
whatever schedule you want)
On Fri, Sep 16, 2016 at 8:18 AM Jonathan Haddad wrote:
> 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 re
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 "production
> ready" rather tha
"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
https://issues.apache.org/ji
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
r
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,
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
It is funny you say this:
"tick-tock started based off of the 3.0 big bang “we broke everything”
release"
*"Brain battles itself over short-term rewards, long-term goals"*
https://www.princeton.edu/pr/news/04/q4/1014-brain.htm
*Normalization of deviance in software: how broken practices become
s
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 <
> bened...@apache.org
>
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 the same cadence as bug fixes.
> They
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 regular cadence makes
Feature releases don't have to be on the same cadence as bug fixes. They're
naturally different beasts.
Why not stick with monthly feature releases, but mark every third (or
sixth) as a supported release that gets quarterly updates for 2-3 quarters?
On Thursday, 15 September 2016, Tyler Hobbs w
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 l
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 bag
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 of
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 tic
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 ideas
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 if
Just another user perspective from someone who manages many clusters:
Tick-tock doesn't really make sense unless at some point you stop ticking.
You can't expect to release features constantly and have a stable product
every tock. Not unless you have really high development, code review, and
testi
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 3.
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 a
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
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 writin
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
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
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. St
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
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
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 Cassan
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,
53 matches
Mail list logo
