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