> > 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). > > >
