Re: [VOTE] Release Apache Cassandra 3.10 (Take 4)
+1 -- Jeff Jirsa > On Jan 13, 2017, at 4:46 PM, Michael Shulerwrote: > > I propose the following artifacts for release as 3.10. > > sha1: 9c2ab25556fad06a6a4d58f4bb652719a8a1bc27 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1136/org/apache/cassandra/apache-cassandra/3.10/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-1136/ > > The Debian packages are available here: http://people.apache.org/~mshuler > > The vote will be open for 72 hours (longer if needed). > > [1]: (CHANGES.txt) https://goo.gl/WaAEVn > [2]: (NEWS.txt) https://goo.gl/7deAsG > > All of the unit tests passed and the main dtest job passed. > > https://cassci.datastax.com/job/cassandra-3.11_testall/47/ > https://cassci.datastax.com/job/cassandra-3.11_utest/55/ > https://cassci.datastax.com/job/cassandra-3.11_utest_cdc/25/ > https://cassci.datastax.com/job/cassandra-3.11_utest_compression/23/ > https://cassci.datastax.com/job/cassandra-3.11_dtest/31/ > > -- > Kind regards, > Michael Shuler >
Re: [VOTE] Release Apache Cassandra 3.10 (Take 4)
+1 On Fri, Jan 13, 2017 at 6:46 PM, Michael Shulerwrote: > I propose the following artifacts for release as 3.10. > > sha1: 9c2ab25556fad06a6a4d58f4bb652719a8a1bc27 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/3.10-tentative > Artifacts: > https://repository.apache.org/content/repositories/ > orgapachecassandra-1136/org/apache/cassandra/apache-cassandra/3.10/ > Staging repository: > https://repository.apache.org/content/repositories/ > orgapachecassandra-1136/ > > The Debian packages are available here: http://people.apache.org/~mshuler > > The vote will be open for 72 hours (longer if needed). > > [1]: (CHANGES.txt) https://goo.gl/WaAEVn > [2]: (NEWS.txt) https://goo.gl/7deAsG > > All of the unit tests passed and the main dtest job passed. > > https://cassci.datastax.com/job/cassandra-3.11_testall/47/ > https://cassci.datastax.com/job/cassandra-3.11_utest/55/ > https://cassci.datastax.com/job/cassandra-3.11_utest_cdc/25/ > https://cassci.datastax.com/job/cassandra-3.11_utest_compression/23/ > https://cassci.datastax.com/job/cassandra-3.11_dtest/31/ > > -- > Kind regards, > Michael Shuler > >
Re: [VOTE] 3.X branch feature freeze
+1 Thanks for bringing this up. On Sat, Jan 14, 2017 at 6:21 AM, Aleksey Yeschenkowrote: > Hi all! > > It seems like we have a general consensus on ending tick-tock at 3.11, and > moving > on to stabilisation-only for 3.11.x series. > > In light of this, I suggest immediate feature freeze in the 3.X branch. > > Meaning that only bug fixes go to the 3.11/3.X branch from now on. > > All new features that haven’t be committed yet should go to trunk only (4.0), > if the vote passes. > > What do you think? > > Thanks. > > -- > AY
Re: [VOTE] Release Apache Cassandra 3.10 (Take 4)
> I propose the following artifacts for release as 3.10. > +1 Thanks!
Re: Wrapping up tick-tock
+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: > 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 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 > wrote: > > > Has any thought been given to SemVer? > > > > http://semver.org/ > > > > -Russ > > > > On 1/13/17, 1:57 PM, "Jason Brown" 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 > > >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 > > >> 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 > > >> 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
Re: Wrapping up tick-tock
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 Jirsawrote: 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 wrote: > Has any thought been given to SemVer? > > http://semver.org/ > > -Russ > > On 1/13/17, 1:57 PM, "Jason Brown" 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 > 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 > > 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 > > 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