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
