Re: [VOTE] Release Apache Cassandra 3.10 (Take 4)

[Jeff Jirsa]

+1

-- 
Jeff Jirsa


> On Jan 13, 2017, at 4:46 PM, Michael Shuler  wrote:
> 
> 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)

[Brandon Williams]

+1

On Fri, Jan 13, 2017 at 6:46 PM, Michael Shuler 
wrote:

> 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

[Nate McCall]

+1
Thanks for bringing this up.

On Sat, Jan 14, 2017 at 6:21 AM, Aleksey Yeschenko  wrote:
> 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)

[Nate McCall]

> I propose the following artifacts for release as 3.10.
>

+1
Thanks!

Re: Wrapping up tick-tock

[Benjamin Roth]

+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

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