cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Roth <benjamin.r...@jaumo.com>
Subject Re: Wrapping up tick-tock
Date Sat, 14 Jan 2017 18:34:23 GMT
+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 <anujw_2003@yahoo.co.in.invalid>:

> 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 confidence on the stability of
> the release , is it a bug fix or a feature release, are there any breaking
> changes or not.
>
> +1 semver and alpha/beta/GA releases
> So that you dont find every second Cassandra user asking about the latest
> stable Cassandra version.
> Thanks
> Anuj
>
>   On Sat, 14 Jan, 2017 at 1:04 AM, Jeff Jirsa<jjirsa@gmail.com> wrote:
>  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 <rbradberry@gmail.com>
> wrote:
>
> > Has any thought been given to SemVer?
> >
> > http://semver.org/
> >
> > -Russ
> >
> > On 1/13/17, 1:57 PM, "Jason Brown" <jasedbrown@gmail.com> 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 major only when we have significant
> >    (possibly breaking) changes/features. It would seem odd to have a 6.0
> >    that's basically the same as 4.0 (in terms of features and
> > protocol/format
> >    compatibility).
> >
> >    Thoughts?
> >
> >    On Wed, Jan 11, 2017 at 1:58 AM, Stefan Podkowinski <spodxx@gmail.com
> >
> >    wrote:
> >
> >    > 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 work on bug fixing (which I think should happen).
> >    >
> >    > On Tue, Jan 10, 2017 at 4:29 PM, Jonathan Haddad <jon@jonhaddad.com
> >
> >    > wrote:
> >    >
> >    > > 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 is directly related to how we pile
> > features
> >    > in
> >    > > for 9 to 12 months and release all at once.  The interactions
> > between the
> >    > > new features are complex and not always obvious.  2.1 was no
> > exception,
> >    > > despite DataStax hiring a full tme test engineering team
> > specifically for
> >    > > Apache Cassandra."
> >    > >
> >    > > 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.
> >    > >
> >    > > Jon
> >    > >
> >    > > On Tue, Jan 10, 2017 at 6:56 AM Jonathan Ellis <jbellis@gmail.com
> >
> >    > wrote:
> >    > >
> >    > > > 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 a kind of theoretical fantasy
> > land of
> >    > > > testing and development resources.  In particular, it takes
> > around a
> >    > > > person-week of effort to verify that a release is ready.  That
> > is,
> >    > going
> >    > > > through all the test suites, inspecting and re-running failing
> > tests to
> >    > > see
> >    > > > if there is a product problem or a flaky test.
> >    > > >
> >    > > > (I agree that in a perfect world this wouldn’t be necessary
> > because
> >    > your
> >    > > > test ci is always green, but see my previous framing of the
> > perfect
> >    > world
> >    > > > as a fantasy land.  It’s also worth noting that this is a common
> >    > problem
> >    > > > for large OSS projects, not necessarily something to beat
> > ourselves up
> >    > > > over, but in any case, that's our reality right now.)
> >    > > >
> >    > > > I submit that any process that assumes a monthly release cadence
> > is not
> >    > > > realistic from a resourcing standpoint for this validation.
> > Notably,
> >    > we
> >    > > > have struggled to marshal this for 3.10 for two months now.
> >    > > >
> >    > > > Therefore, I suggest first that we collectively roll up our
> > sleeves to
> >    > > vet
> >    > > > 3.10 as the last tick-tock release.  Stick a fork in it, it’s
> > done.  No
> >    > > > more tick-tock.
> >    > > >
> >    > > > I further suggest that in place of tick tock we go back to our
> > old
> >    > model
> >    > > of
> >    > > > yearly-ish releases with as-needed bug fix releases on stable
> > branches,
> >    > > > probably bi-monthly.  This amortizes the release validation
> > problem
> >    > over
> >    > > a
> >    > > > longer development period.  And of course we remain free to ramp
> > back
> >    > up
> >    > > to
> >    > > > the more rapid cadence envisioned by the other proposals if we
> > increase
> >    > > our
> >    > > > pool of QA effort or we are able to eliminate flakey tests to
> > the point
> >    > > > that a long validation process becomes unnecessary.
> >    > > >
> >    > > > (While a longer dev period could mean a correspondingly more
> > painful
> >    > test
> >    > > > validation process at the end, my experience is that most of the
> >    > > validation
> >    > > > cost is “fixed” in the form of flaky tests and thus does not
> > increase
> >    > > > proportionally to development time.)
> >    > > >
> >    > > > Thoughts?
> >    > > >
> >    > > > --
> >    > > > Jonathan Ellis
> >    > > > co-founder, http://www.datastax.com
> >    > > > @spyced
> >    > > >
> >    > >
> >    >
> >
> >
> >
> >
>



-- 
Benjamin Roth
Prokurist

Jaumo GmbH · www.jaumo.com
Wehrstraße 46 · 73035 Göppingen · Germany
Phone +49 7161 304880-6 · Fax +49 7161 304880-1
AG Ulm · HRB 731058 · Managing Director: Jens Kammerer

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message