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:kenbrot...@yahoo.com.INVALID] Sent: Wednesday, April 04, 2018 4:51 PM To: dev@cassandra.apache.org 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:kenbrot...@yahoo.com.INVALID] Sent: Wednesday, April 04, 2018 4:23 PM To: dev@cassandra.apache.org 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:sc...@paradoxica.net] Sent: Wednesday, April 04, 2018 4:18 PM To: dev@cassandra.apache.org 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 <kenbrot...@yahoo.com.INVALID> Sent: Wednesday, April 4, 2018 2:20:59 PM To: dev@cassandra.apache.org 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:zznat...@gmail.com] 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 <kenbrot...@yahoo.com.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-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
