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 > > > > > >
