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 y
+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 make life easier for Cassandra us
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 confid
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 been given to SemVer?
>
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 think we should up the
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
> wrote:
>
> > It's fine to lim
+ 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 months have
> passed. I thin
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 basically
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 w
+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 internally.
+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.
> >
>
> Let's please do put thi
>
> 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.
+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
> 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
> mo
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
>
> 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
testfi
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 ge
+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 release, but I also agree
> > with Jon that we s
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 up several times now as
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 commi
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
supp
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
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. This
Hi all,
We’ve had a few threads now about the successes and failures of the
tick-tock release process and what to do to replace it, but they all died
out without reaching a robust consensus.
In those threads we saw several reasonable options proposed, but from my
perspective they all operated in
24 matches
Mail list logo
