Problem/Motivation

Closely related to #2598662: Decide when Drupal 7 (and Drupal 8 and later) should enter the LTS and security-support-only phase, except that's about when the branches start LTS, this is about when they are designated as being at end of life (EOLed).

For reference 5.x EOL was on the day 7.x was released.

Drupal 6 EOL is three months after 8.0.0 release.

The Drupal 8 LTS (Long Term Support) will be released sometime between the opening and release of 9.0.0

Things to consider:

1. How many major core branches are supported at once? The current LTS policy says 2 with a 3 month crossover, is that a hard maximum?

2. If we end up with two LTS releases of 8.x for any reason, would that affect the number of major branches we'd want to support.

3. Do we expect people to migrate from 7.x to 8.x when the migration is available, or wait for 9.x? When will the 7-8 migration be available?

4. Do we expect people to migration from 8.x to 9.x (especially if that's a smaller jump) or wait for 10.x?

5. If 9.x ships with a fully support migration path from 7.x, how much time is reasonable to allow people to jump if we support that?

6. Do we want to support going from 7.x LTS to 9.x LTS, or just to 8.x LTS and 9.x minor releases - the answer to #1 affects the feasibility of this

7. What's going to happen with D6 extended support? How quickly with 6.x usage drop off on http://drupal.org/project/usage/drupal? Will we finally see the remaining hard-core 5.x sites disappear?

8. Given we've shifted to a timed release cycle for new releases, would we consider moving to timed EOL, for example LTS + 2 years? Instead of pinning it to major version + 2 release dates which is more variable.

(add more if you have them)

Proposed resolution

A few examples of what we could do:

Option 1

Drupal 10.0.0 + 3 months (same as 6.x EOL timing)

Option 2

Drupal 10.0.0 release day (same as 5.x EOL timing)

Option 3

Drupal 10.X.0 LTS release day (allows for LTS to LTS)

Option 4

Drupal 9.X.0 LTS + 1 year (assumes we start only supporting version N to version N + 1 again and make the upgrade path smoother.

Option 5

Drupal 8.X.0 LTS + 2 years (allows us to announce the actual date much earlier than any of the other options, because it's only based on the 8/9 release cycle).

Add more options here.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

catch created an issue. See original summary.

catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
Charles Belov’s picture

Issue summary: View changes

Expanded EOL on first use for benefit of those not familiar with the jargon. Please expand the acronym LTS on first use for the benefit of those of us not familiar with the term.

caspervoogt’s picture

Issue summary: View changes
xjm’s picture

xjm’s picture

Moving my comments from #2598662: Decide when Drupal 7 (and Drupal 8 and later) should enter the LTS and security-support-only phase (I keep confusing these two issues).

This will become even more the case for security support... It's hard to imagine being able to maintain security support for D7 for 4+ more years as in the current illustration, but the intent of that was so that risk-averse organizations could go from 7.x LTS to 9.x LTS.

I am not sure we will actually be able to offer security support for D7 until the creation of a 9.x LTS, so maybe we shouldn't imply that we will until we have some confidence and also actual experience with the 6.x extended LTS thing. It's what would be most advantageous to some audiences, but better to under-promise rather than over-promise.

aangel’s picture

xjm: why do you say "I am not sure we will actually be able to offer security support for D7 until the creation of a 9.x LTS?"

Is it a matter of much work there will be for the community or a concern with the infrastructure of D7 that causes you to say that?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

catch’s picture

Is it a matter of much work there will be for the community

For previous releases, we've supported a maximum of two major branches at a time for security.

When 8.x came out, 6.x was supported for an additional three months - meaning support for three branches at once. Additionally there was work to co-ordinate commercial LTS for after that point (and for that LTS support to be provided in such a way that any fixes resulting from it would be free via http://drupal.org/project/d6lts).

Supporting 7.x until the 9.x LTS comes out means potentially supporting 7.x, 8.x and 9.x simultaneously for years rather than months. If the 9.x LTS is 'when 10.x development starts', we have absolutely no idea when that will be. We don't even know when the 9.x branch will open yet.

The previous discussion for 6.x support at #2136029: Decide if and how to extend D6 security support 3 months past an 8.0.0 release has a lot of background on how this means additional work. That additional work isn't for the community as a whole, but specifically for people on the security team - the whole point of 'security support' is fixing issues in private before they're disclosed.

stefan.r’s picture

I am not sure we will actually be able to offer security support for D7 until the creation of a 9.x LTS, so maybe we shouldn't imply that we will until we have some confidence and also actual experience with the 6.x extended LTS thing. It's what would be most advantageous to some audiences, but better to under-promise rather than over-promise.

Probably #2608062: [policy, no patch] Pre-requisites for opening Drupal 9 needs to be discussed a bit more before we can, but can we at least communicate some date and revise it upwards later? A piece of information many are interested in is, for how many years will D7 still be supported, and currently this is completely undetermined.

Per the discussions in this thread, at this point any D7 EOL dates based on a 9.x.0 LTS seem to be premature, so could we at least say something like, "9.0.0 + X years", along with "9.0.0 definitely won't be released before Y date", where any of "9.0.0", "X years", and "Y date" can be adjusted upwards later?

caspervoogt’s picture

@stefan.r, good idea. And once 9.x.0 LTS details are more firm, those figures can be updated accordingly.

catch’s picture

Issue tags: +security

I've done a major update to #2608062: [policy, no patch] Pre-requisites for opening Drupal 9 which would commit us to doing a fair number of things before opening the 9.x branch.

Any commitment to 9.0.0 + X time needs discussion with the security team, so tagging for that. The baseline has been dropping X -1 when X + 1 opens, and 6.x got an extra 3 months due to exceptional circumstances. Not sure how people feel about things for 7.x - there's more test coverage, more sites using it, not less divergence though.

When I've brought up picking absolute dates (like 'not before 2019') or similar there's been a concern that people will just see 2019 and panic, when we might not even open 9.x until 2020 or whenever.

So seems easier to agree on the 9.x pre-requisites first then extrapolate some idea of dates based on that.

eelkeblok’s picture

An important consideration should be that a move from D7 to D8 is likely to be quite involved. It might well be the last of the "rebuild upgrades" as we've become used to in the Drupal world, with much more smooth transitions going from e.g. the last 8.x to 9.0, but it shouldn't be ignored.

New sites are still built in D7 right now, so ideally we should ensure that such sites have a reasonable lifetime before we need to tell our clients, "Hey, we better build you a new site, because your current Drupal version is not going to be supported anymore". I'd say that means that D7 LTS needs to last for at least 4 more years. Preferably longer (4 years would actually be quite soon for us to have the aforementioned conversation with clients, and we would like some leeway to actually build the new site as well).

Another consideration should probably be, how much of an extra burden is supporting "9.x" in addition to supporting D8 LTS (This burden is likely to increase the more D9 moves away from 9.0 and therefore 8 LTS).

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Leo Pitt’s picture

Just seen this thread. I'd agree with eelkeblok. Requesting a client invest a lot more budget in effectively rebuilding their site < 4 years after it being created, could lead to some resentment and not great for Drupal agencies or their clients.

I'd say having a reasonably robust upgrade path from D7 to D8 (minimum) and D9, should be a criteria for D7 EOL.

sunward’s picture

I am currently upgrading from 6 to 7. If I wanted to upgrade to 8 I couldn't as many modules are not available yet or stable in version 8. And now there is talk of version 9 and even 10?

I understand the idea of keeping Drupal current, but why start a new project when the older one isn't even finished?

Perhaps it is time to stop coming out with a new major rebuild every 2 years and start getting the current build fully functional and usable. Once done, then upgrade continuously as the trend is now with such projects as firefox, chrome, etc.

daften’s picture

@sunward: that's what's happening now in Drupal 8 with the minor versions being released every 6 months: https://www.drupal.org/core/release-cycle-overview
However, releasing a new major version HAS to be done at some point, to remove deprecated parts of the code. This issue is to discuss when and how that should occur.

eelkeblok’s picture

Strictly speaking, that point is being discussed in the other issue: #2608062: [policy, no patch] Pre-requisites for opening Drupal 9. However, up till now, releasing a new major version has been pretty closely tied to dropping support of previous major versions. But I think making that tie less strict, or removing it altogether, is at least open to discussion here. If 9.0 would be released within some timeframe after releasing 8.0 that we consider unreasonable to stop support for 7 (I've mentioned 4 years above), we should seriously consider removing that strict tie. Having said that, I would expect that to be a non-issue as 9.0 is unlikely to drop that soon. Or is it?

What makes this hard is that the new release cycle has upended things and we as a community don't really know what to expect either. This also makes D7 somewhat of a special case, since it is the last of the major releases of doing it the old way.

catch’s picture

@sunward if we don't talk about this long in advance, then we can't plan for it. Drupal 8 was opened without having discussed either Drupal 6 or Drupal 7 LTS support or how the release cycle would look, that's partly why it took over 4 years to release as well.

As well as the issue @eelkebrok linked in #19, there's also #2822727: [policy, no patch] Adopt a continuous API upgrade path for major version changes which is RTBC. All of those discussions affect this one.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.