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/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644598180f950ff4f478@%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
