cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Jirsa <jji...@gmail.com>
Subject Re: Wrapping up tick-tock
Date Fri, 13 Jan 2017 19:34:57 GMT
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
>     > > >
>     > >
>     >
>
>
>
>

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