osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Roadmap for 4.0


So in a vibrant community like ours, each year it is reasonable to expect
that some new features will be ready.  We probably can't predict far in
advance which ones.  So each year whatever is ready, is included in that
year's major release (using a 12 month cycle as an example) and then no one
is rushing to meet a deadline because they are holding up a version, because
that feature will just be able to go in the next version.  No pressure; and
no energy discussing how we will approach each version.  That's a lot of
high caliber talent we are consuming.

Kenneth Brotman

-----Original Message-----
From: Kenneth Brotman [mailto:kenbrotman@xxxxxxxxx.INVALID] 
Sent: Wednesday, April 04, 2018 4:51 PM
To: dev@xxxxxxxxxxxxxxxxxxxx
Subject: RE: Roadmap for 4.0

The group seems to be trying to find a set of features that will define
version 4.0.  I'm saying that makes things way too complicated.  You'll
drift, time will go by, no release because of this or that.  I'm saying
instead, accept that you can't know the time frame really that it will take
to properly develop and test a feature.  You won't want to release it until
it's ready.  So take the pressure and complication out of it.

Every once in a while a nice set of features will be ready and should not be
delayed when they are.  That's when you have a new major release.  Let it
happen more naturally instead of forcing it.

Kenneth Brotman

-----Original Message-----
From: Kenneth Brotman [mailto:kenbrotman@xxxxxxxxx.INVALID]
Sent: Wednesday, April 04, 2018 4:23 PM
To: dev@xxxxxxxxxxxxxxxxxxxx
Subject: RE: Roadmap for 4.0

I wouldn't want to add anything to a release that isn't ready.  Whatever
isn't ready can go in a future release. 

-----Original Message-----
From: Scott Andreas [mailto:scott@xxxxxxxxxxxxxx]
Sent: Wednesday, April 04, 2018 4:18 PM
To: dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: Roadmap for 4.0

Re-raising a point made earlier in the thread by Jeff and affirmed by Josh:

---
Jeff:
>> A hard date for a feature freeze makes sense, a hard date for a 
>> release does not.

Josh:
> Strongly agree. We should also collectively define what "Done" looks 
> like post freeze so we don't end up in bike-shedding hell like we have 
> in the past.
---

Another way of saying this: ensuring that the 4.0 release is of high quality
is more important than cutting the release on a specific date.

If we adopt Sylvain's suggestion of freezing features on a "feature
complete" date (modulo a "definition of done" as Josh suggested), that will
help us align toward the polish, performance work, and dog-fooding needed to
feel great about shipping 4.0. It's a good time to start thinking about the
approaches to testing, profiling, and dog-fooding various contributors will
want to take on before release.

I love how Ben put it:

> An "exciting" 4.0 release to me is one that is stable and usable with 
> no perf regressions on day 1 and includes some of the big internal 
> changes mentioned previously.
>
> This will set the community up well for some awesome and exciting 
> stuff that will still be in the pipeline if it doesn't make it to 4.0.

That sounds great to me, too.

- Scott

________________________________________
From: Kenneth Brotman <kenbrotman@xxxxxxxxx.INVALID>
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@xxxxxxxxxxxxxxxxxxxx
Subject: RE: Roadmap for 4.0

Focusing on 4.0 release then, lets agree on a date next year. Whatever is
ready for release by that date is what will be in that release.

Kenneth Brotman

-----Original Message-----
From: Nate McCall [mailto:zznate.m@xxxxxxxxx]
Sent: Wednesday, April 04, 2018 12:59 PM
To: dev
Subject: Re: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
<kenbrotman@xxxxxxxxx.invalid> wrote:
> Can I suggest a way of defining the next few progressions as a way of
approaching this?
>
> How about something like this:
>         Version 4.0:  A major release of as many improvements to the 
> code
as can be ready for a release on a date sometime next year ;to be decided on
by us this month.
>         Versions 4.x: minor releases about every three months starting
after a major release with improvements to the code that can be ready for
release, with bug fixes as needed done in between.
>         Version: 5.0: a major release of whatever significant 
> improvements
are ready for release one year after the release of 4.0
>         Versions 5.x: minor releases about every three months with
improvements, with bug fixes as needed done in between,
>         And so on:
>                 A Major release every 12 months of whatever can be 
> ready
for release in that major version,
>                 A minor release every 3 months of whatever can be 
> ready
for release in that minor version.
>                 Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code 
> would
be ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of discussion.
Please see the following two (lengthy) threads from last year for
background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb
9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644
598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx