+1 to what Jon and Josh said. At this point in time, 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. On Wed, Apr 4, 2018 at 11:00 AM Jon Haddad <j...@jonhaddad.com> wrote: > Agreed with Josh. There’s nothing set in stone after we release 4.0, > trying to extrapolate what we do here for the rest of humanity’s timeline > isn’t going to be a useful exercise. > > Regarding building a big list - it’s of no value. In fact, if we’re > already talking about releasing 4.0 we should really only be merging in > small features that enhance user experience like improving nodetool output > or reasonable optimizations. Merging in big features at the very end of > the merge window is a really great idea to have dozens of follow up bug fix > releases that nobody considers stable, where the Coli conjecture always > wins. IMO, it would be better / more responsible to merge them into trunk > *after* we branch for 4.0. Yes, that makes the next release less exciting, > but I really don’t think “exciting” is what we’re shooting for. I’m more > in favor of stable. > > Regarding supporting 3.0 / 3.11, since we’re talking about feature > freezing 4.0 2 months from now, and releasing it *sometime* after that, > then add 6 months, we’re talking about close to an extra year of 3.0 > support. People are, of course, free to continue patching 3.0, back > porting fixes, etc, but I am completely OK with saying there’s only 9 more > months of support starting today. > > I’m also in the go straight to 3.11 camp. I see no reason to upgrade to > only 3.0 if you’re on 2.x. > > Jon > > > On Apr 4, 2018, at 6:29 AM, Josh McKenzie <jmcken...@apache.org> wrote: > > > >> > >> This discussion was always about the release strategy. There is no > >> separation between the release strategy for 4.0 and the release strategy > >> for the project, they are the same thing and what is intended to be > >> discussed here. > > > > Not trying to be pedantic here, but the email thread is titled "Roadmap > for > > 4.0" and has been concerned with how we get 4.0 out the door. I don't > think > > it's implicit that whatever strategy we settle on for 4.0 is intended to > > apply to subsequent releases, since the 3.0.X to 3.X to 4.0 > > relationship/delta is different than a 4.0 to 5.0 can be expected to be. > > > > > >> sidenote: 3.10 was released in January 2017, and while the changes list > for > >> 4.0 is getting quite large there's not much there that's going to win > over > >> users. It's mostly refactorings and improvements that affect developers > >> more so than users. > > > > If you assume most 3. users are on 3.10, this argument makes sense. I > > believe a majority are on 3.0.X or 2.1/2.2, which leaves a minority > looking > > at the small delta from 3.10 to 4.0 in the current form. > > > > > > > > On Wed, Apr 4, 2018 at 8:25 AM, kurt greaves <k...@instaclustr.com> > wrote: > > > >>> > >>> I'm also a bit sad that we seem to be getting back to our old demons of > >>> trying > >>> to shove as much as we possibly can in the next major as if having a > >>> feature > >>> miss it means it will never happen. > >> > >> That wasn't the intention of this thread, but that's the response I got. > >> Thought I made it pretty clear that this was about compiling a list of > >> things that people are currently working on and can commit to getting > >> finished soon (which should be a relatively small list considering the > >> limited number of full time contributors). > >> > >> Of course, we should probably (re-(re-(re-)))start a discussion on > release > >>> "strategy" in parallel because it doesn't seem we have one right now, > but > >>> that's imo a discussion we should keep separate. > >> > >> This discussion was always about the release strategy. There is no > >> separation between the release strategy for 4.0 and the release strategy > >> for the project, they are the same thing and what is intended to be > >> discussed here. I don't think it's possible to have a separate > discussion > >> on these two things as the release strategy has a pretty big influence > on > >> how 4.0 is released. > >> > >> I'm all for a feature freeze and KISS, but I feel that this really > needs a > >> bit more thought before we just jump in and set another precedent for > >> future releases. IMO the Cassandra project has had a seriously bad track > >> record of releasing major versions in the past, and we should probably > work > >> at resolving that properly, rather than just continuing the current > "let's > >> just try something new every time without really thinking about it". > >> > >> Some points: > >> > >> 1. This strategy means that we don't care about what improvements > >> actually make it into any given major version. This means that we will > >> have > >> major releases with nothing/very little desirable for users, and thus > >> little reason to upgrade other than to stay on a supported version > (from > >> experience this isn't terribly important to users of a database). I > >> think > >> this inevitably leads to supporting more versions than necessary, and > in > >> general a pretty poor experience for users as we spend more time > >> fighting > >> bugs in production rather than before we do a release (purely because > of > >> increased frequency of releases). > >> 2. We'll always be driven by feature deadlines, which for the most > part > >> is fine, as long as we handle verification/quality assurance/release > >> candidates appropriately. The main problem here though is that we > don't > >> really know what's going to be in a certain release until we hit the > >> freeze, and what's in it may not really make sense at that point in > >> time. > >> 3. We'll pump out major versions fairly regularly and end up with even > >> more users that are on EOL versions with complex upgrade paths to get > >> to a > >> supported version or a version with a feature they need (think all > those > >> people still out there on 1.2). > >> 4. This strategy has the positive effect of allowing developers to see > >> their changes in production faster, but OTOH if no one really uses the > >> new > >> versions this doesn't really happen anyway. > >> > >> I'd also note that if people hadn't noticed, users tend to be pretty > >> reluctant to upgrade their databases (hello everyone still running 2.1). > >> This tends to be the nature of a database to some extent (if it works on > >> version x, why upgrade to y?). IMO it would make more sense to support > less > >> versions but for a longer period of time. I'm sure most users would > >> appreciate 2 years of bug fixes for only 2 branches with a new major > >> approximately every 2 years. Databases don't move that fast, there's not > >> much desirable in a feature release every year for users. > >> > >> sidenote: 3.10 was released in January 2017, and while the changes list > for > >> 4.0 is getting quite large there's not much there that's going to win > over > >> users. It's mostly refactorings and improvements that affect developers > >> more so than users. I'm really interested in why people believe there > is an > >> actual benefit in pumping out feature releases on a yearly basis. Who > >> exactly does that benefit? From what I know, the majority of "major" > users > >> are still backporting stuff they want to 2.1, so why rush releasing more > >> versions? > >> > >> Regardless of whatever plan we do end up following it would still be > >>> valuable to have a list of tickets for 4.0 which is the overall goal of > >>> this email - so let's not get too worked up on the details just yet > (save > >>> that for after I summarise/follow up). > >>> > >> lol. dreaming. > >> > >> On 4 April 2018 at 10:38, Aleksey Yeshchenko <alek...@apple.com> wrote: > >> > >>> 3.0 will be the most popular release for probably at least another > couple > >>> years - I see no good reason to cap its support window. We aren’t > Oracle. > >>> > >>> — > >>> AY > >>> > >>> On 3 April 2018 at 22:29:29, Michael Shuler (mich...@pbandjelly.org) > >>> wrote: > >>> > >>> Apache Cassandra 3.0 is supported until 6 months after 4.0 release > (date > >>> TBD). > >>> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Ben Bromhead CTO | Instaclustr <https://www.instaclustr.com/> +1 650 284 9692 Reliability at Scale Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
