Has any thought been given to SemVer?
http://semver.org/
-Russ
On 1/13/17, 1:57 PM, "Jason Brown" <jasedbr...@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 <spo...@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 <j...@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 <jbel...@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
> > >
> >
>
