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 you talk to long term Cassandra users, most of them will form their opinion on release stability based on how long the release branch has been available and how long it received bug fixes, and also based on Jira activity / known issues. New users will probably just start with the latest version, but I still think they also understand that newer releases will be less stable than releases maintained for a while. That's why I find it less important to rubber-stamp a release as "stable", but instead to give a clear picture on the first .0 release date, the EOL date and included features and let the user pick his poison, as it's a trade-off after all. We could however list new features as "beta" there, if that would help users to consider if their next mission critical application should be based on MV or CDC (just to give an example). On Sat, Jan 14, 2017 at 7:07 PM, Anuj Wadehra < anujw_2...@yahoo.co.in.invalid> wrote: > 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<jji...@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 <rbradbe...@gmail.com> > wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > >
