Some unfinished business from #2135189: Proposal to manage the Drupal core release cycle is that it's not clear when Drupal 7 should enter the LTS (long term support) phase (only bugfixes and security fixes allowed), and when it should enter the final support phase in which only security fixes are allowed.

Based on the diagram in that issue:

  • Drupal 7 would have already been in the LTS phase for a while (we missed the boat on that).
  • Drupal 8 would enter LTS around the time Drupal 9 is opened for development. Sites using Drupal 8 don't get new features anymore until Drupal 9 is stable and they actually decide to upgrade to it.
  • Drupal 7 would enter the security-support-only phase 3 months after Drupal 8 enters the LTS, and Drupal 8 would enter that phase 3 months after Drupal 9 enters the LTS.

But there wasn't a whole lot of discussion of the above - and again, for #1 we missed the boat (already missed it before that issue even existed).

Some competing goals in determining these dates include:

  1. Letting people who only want to use LTS releases still get to use the new version of Drupal sooner rather than later.
  2. Not having too long of a period where the current release of Drupal core has stopped getting new features, but the next release of Drupal core is nowhere near the point where it will be used on actual sites.

We have to figure this all out at some point, but not necessarily right away - hence priority = "major" for now.

Decisions to make:

  1. When does D7 enter LTS?
    • Current policy says it already was, but this isn't actually true.
    • Proposal from Dries and D8 committers: once D7/8 Migration is fully supported.
  2. When does D7 LTS end and security-only support begin?
    • Current policy: When D8 LTS is available.
  3. When does D8 LTS begin?
    • Current policy: next scheduled minor after 9.0.x opens for development
    • Proposed modification: When 9.0.0 is released. (Illustrations in #19.)
  4. When does D8 LTS end and security-only support begin?
    • Current policy: when D9 LTS is available.
  5. When is D7 EOL? Disucssed in #2608496: [policy, no patch] Drupal 7 (and 8) EOL timing
  6. When is D8 EOL? Disucssed in #2608496: [policy, no patch] Drupal 7 (and 8) EOL timing

Proposed resolution

D7 LTS should start once the D7/8 migration path is fully supported.
D7 LTS should end once D8 LTS begins, same as the current policy. This is essential for LTSes to meet the need they're intended for.
D8 LTS should be released at the same time as 9.0.0.
D8 LTS should end once D9 LTS begins.
D9 LTS should end once D10 LTS begins.

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

David_Rothstein created an issue. See original summary.

David_Rothstein’s picture

Issue summary: View changes
David_Rothstein’s picture

Issue summary: View changes
David_Rothstein’s picture

My general thought:

  1. "People who only want to use LTS releases" is not a real category. What actually exists is "people who value stability over everything else".
  2. Much as we wouldn't like it to be the case, security fixes are usually more likely to break things than new features are.

So I think it would make more sense to talk about a time after which we put an extra focus on stability (and calling that an "LTS"), but that doesn't mean we can't add new features during that time period if people want to add them. It just means we get much more strict about backwards compatibility and put the brakes on any features that don't meet those requirements.

The date at which we stop doing features and stop doing non-security bugfixes... does it need to be planned this far in advance at all, or is it more something that depends on community resources and if there are actually people who are willing to keep working on those items?

David_Rothstein’s picture

David_Rothstein’s picture

Issue tags: +Project governance
catch’s picture

There are a couple of things for me which I think we need an idea about before we can usefully discuss this, and they're called Drupal 9 and Drupal 10.

The effort involved in upgrading a site from Drupal 6 to either Drupal 7 or Drupal 8, is going to be anything from 30% to 125% of the time that was spent building the initial 6.x site. For that reason, many sites skip major Drupal versions so that they only have to do that big outlay every 5-7 years instead of every 2-4. This is I think the motivation behind the LTS-to LTS+2 cycle that's in the diagram. While there is definitely a stability-first-and-only audience for major core versions, I also feel like this is based on current rather than future reality for what major core version upgrades entail. It is going to be the case for 7.x 8.x or 9.x, but it might not be the case for 8.x to 9.x and 10.x.

While there might be different ideas about what Drupal 9 looks like, I don't think anyone wants the release cycle to look the same as the 6.x-7.x or 7.x-8.x release cycles - both of which took a very, very long time. Also I don't think anyone wants a situation where 9.x is released more than 6-12 months after 8.x development de-facto stops since then we get into multi-year waits for new core functionality again. (Apologies to those that love multi-year waits if your views weren't represented).

However while we've adopted six-monthly minor releases for the 8.x cycle, and agreed not to open Drupal 9 until an undetermined point in the future, there has not been much discussion of what the Drupal 9 development cycle itself looks like.

For me personally, I think we should aim to keep to a six month release cycle whether it's major or minor versions.

This would mean that either we release 9.0.0 six months after the final minor release of 8.x (which would also be the LTS), OR we release the final minor release of 8.x on the same day as 9.0.0. (Or there's a further variation that we do two 8.x LTS releases, with the second being as compatible with 9.x as possible similar to what Symfony's doing with 2.7/2.8 and 3.0).

The 'start of a major core version' has generally been when the branch is officially opened for development, but as 8.x showed quite dramatically, the opening of the branch doesn't necessarily have any correlation to significant work going in or getting done - no significant 8.x patches landed for at least 6 months after the branch was opened, so it could as well have remained shut.

What really slows down the development of stable core versions is when the following two things happen:

1. Patches stop being cherry-pickable from the development release to the previous release
2. Contrib modules are impossible to run on the new version, which by extension means that new modules/functionality can't easily be ported between core versions either due to API incompatibility.

When we get to that point, is when 8.x development will grind to a standstill, and we go into 'LTS-mode' - whether it meets the official timing or not.

We've addressed part of this by agreeing not to open the 9.x branch officially until some kind of significant work is ready (that can't be completed in 8.x). What I think we're missing is a way to go from that branch opening to a release candidate in a short period of time.

Unlike the 8.x release, it should be feasible for 9.x to have full migration paths from both 7.x and 8.x (and even 6.x if we wanted to, although we'd probably move that to contrib) from the moment it opens right through until RC - this means full 7.x and 8.x source migrations in the 8.x branch before 9.x is open, and then 9.x only has to update the migration destinations when there are breaking changes to them.

Additionally if significant work is ready before it goes into 9.x trunk, then a lot of the work that has to happen after 9.x is actually opened, is things like dropping bc layers, conversions of core from newly deprecated APIs, and resolving merge conflicts (in the broadest sense, including API incompatibiltiy between new modules and core subsystem changes etc.) between different bits of work that have gone in. These are the kinds of things that will stall 8.x development (at least for code that's impacted). Everything else ought to be resolvable either beforehand, or in minor releases. If we handle that well, then I think it could be realistic to go from initial merges to release candidate within 9 months if not much sooner. Maybe even 3 months if there's only a couple of huge changes to convert things to.

In case you are sitting there laughing, remember that Drupal 6.0 was released only 13 months after Drupal 5.0. It's really Drupal 7 where we switched from timely core releases to, um, not timely releases.

If the overall change from the last 8.x minor release to 9.0.0 is significantly smaller than from 7.0 to 8.0.0, then the upgrade for both contrib modules and actual sites from Drupal 8 to Drupal 9 is potentially a lot smaller to. Then again for Drupal 9 to 10. At that point, the ability to jump an entire release and land on an LTS becomes less important.

If we get to smoother updates for contrib and data, then it seems fine to me to drop 7.x support 3 months after 9.0.0 is released, the same as we're doing with 6.x - given it will have a full migration path and probably more modules ported at that point than 6.x does.

The remaining question then is how long we consider to be reasonable for the minimum lifecycle of a newly built site. People are going to be either building new sites or upgrading to 7.x until three months after 8.0.0 is released - either because they started before the RC came out, or to get off 6.x quickly. They are going to want some kind of buffer before having to do a major version upgrade again, and that is going to depend on how long there is between 8.0.0, 9.0.0 and 10.0.0 regardless of when support is officially dropped for 7.x.

So instead we should consider completely reversing

This way, we'd tie the 8.x LTS not to the /start/ of 9.x

For me personally, I think we should aim to release the final 8.x minor version on the same day that 9.0.0 is released

Fabianx’s picture

For me it is a matter of deprecation.

e.g. we introduce new APIs in 8.x, deprecate the old APIs and remove in 9.x.

I think with that you are always one step ahead in the current major version and things are way more smoothly.

There is almost nothing that cannot be done in a BC compatible way.

And breaking BC == upgrade path + change records anyway.

However there might be some very seldom more invasive things and those could really live only in 9.x, but I think overall that would be the minority and not the majority.

90% of things should use the deprecate in 8.x.0 and remove in 9.0.0 pattern IMHO.

Overall many of Drupal 7's functions can be mapped 1-1 to 8.x functionality and vice versa - so 4 years ago even a compatibility layer between 7.x and 8.x would have been feasible except for maybe things like Entity API (it still is feasible - just a very major effort).

e.g. drupal_set_message => interface conversion did not make it into 8.0.x and removal of drupal_set_message hence for 8.y.0 is impossible.

However we can use the following 3-step pattern to smoothly convert it without breaking BC:

Step 1 (8.x.0):

- Adding of MessengerInterface (API addition)
- Adding of a LegacyMessenger, which calls a $drupal7->drupal_set_message compatibility layer plus unit tests.
- Mapping of LegacyMessenger to 'messenger' service and registering in Container.

By now the 'messenger' service is fully usable without having to write any kind of conversion besides mapping of new functions to old. That keeps technical burden to a minimum and keeps 100% BC.

An early notice is placed on drupal_set_message / drupal_get_message that it will be deprecated in 8.y.0 - as deprecation can still create test fails.

Step 2 (8.y.0):

- Now the MessengerInterface can be used to create a real messenger service using e.g. the Symfony session service injected.
- The 'messenger' service is swapped out.
- drupal_set_message / drupal_get_message are deprecated with a trigger_error() and calls the new messenger service via functions of \Drupal::service('messenger')
- A notice is placed that drupal_set_message / drupal_get_message / LegacyMessenger will be removed in 9.0.0.

Step 3 (9.0.0):

- The LegacyMessenger class and drupal_set_message / drupal_get_message are removed

catch’s picture

Yes we should be doing things like that throughout the 8.x release cycle.

Doing so means that the only things we have to do for 9.0.0 are 1. remove deprecations 2. make changes that can't be resolved via deprecations - since by design everything else could happen for 9.1.0.

chx reminded me that release timings actually began slipping with Drupal 4.7, which effectively had two development cycles via form API being started when it otherwise would have gone to beta/release candidate.

4.5.0 - 4.6.0: 6 months
4.6.0 - 4.7.0: 13 months
4.7.0 - 5.0: 7 months
5.0 - 6.0: 13 months
6.0 - 7.0: 35 months
7.0-8.0.0: 46+ months

So the question is, can we make the next entry:

8.5.0-9.0: 6 months

And what are the ramifications of that if we do.

Charles Belov’s picture

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

Fabianx’s picture

LTS == Long Term Support - the same as Ubuntu LTS - receives (critical) bug fixes and security fixes only, but until a long time.

catch’s picture

Issue summary: View changes
xjm’s picture

xjm’s picture

So I think it would make more sense to talk about a time after which we put an extra focus on stability (and calling that an "LTS"), but that doesn't mean we can't add new features during that time period if people want to add them. It just means we get much more strict about backwards compatibility and put the brakes on any features that don't meet those requirements.

I don't agree with this. In order to respect semver, a minor version cannot contain any new features or APIs only minor versions can contain new features or APIs, and the point of the LTS is that it's a single extended minor that only gets patch releases until its EOL. Based on my experience working at a university, we would have opted for that -- minimal upgrades for patch releases, and nothing new, because there's always the risk of something breaking the site no matter how careful, and we simply didn't have the resources or willingness to risk it. This is one of the reasons that so many sites stay on old versions of Drupal. It also is, as you said, dependent on community resources, and we know that currently there are limited resources available for maintaining D7 core and contrib, to say nothing of D6. So I think D7 should be in LTS as of the release of 8.0.0, or at least some time in the next six months, with only the patch release allowed changes.

I also think that in order for the D7 LTS to truly meet the usecase -- that of people who don't want to do a minor version upgrade every six months -- it needs to continue until the 8.x LTS is available plus time to do the migration, as in the original proposal. So that means that the later we wait to make a D8 LTS, the longer we need to support D7. It also needs to be predictable and announced well in advance, because the other thing that the LTS audience needs is ample time to secure resources for their upgrade. I'd say at least a year given budgets and such -- so if we decide that 8.5.x is going to be the LTS, we should try to announce that as of 8.3.x, or be prepared to extend D7 support longer in order to give that advanced warning.

I think in order to make the best decision, we need to see how 8.0.0 adoption and D6 and D7 migrations go, and to see how minors work out. I also agree with David that we need to be aware of what resources are available. Edit: I confused this with #2608496: [policy, no patch] Drupal 7 (and 8) EOL timing; reposting some things over there.

So in summary:

  • 7.x LTS should be equivalent to a single minor version with bugfixes only.
  • 7.x LTS needs to be supported until 8.x LTS + time to upgrade.
  • We should try to plan and announce which release the 8.x LTS will be a year (two 8.x scheduled minors) in advance.
  • I think 7.x LTS should start no later than 8.1.0 and possibly on November 19 when the migration path is fully supported.
xjm’s picture

Reposting a useful comment from @effulgentsia in #2597872: Allow features to be added during the beta phase, especially if they are backportable to the previous version that's more in scope for this issue:

However, since then, Symfony decided on releasing a 2.8 LTS on the same day as 3.0. So catch's suggestion of doing similar for an 8 LTS on the same day as 9.0 is definitely worth considering. However, unless we're willing to have multiple LTS's within a single major, as Symfony does, this would delay 8's LTS relative to our earlier thinking, which might have down sides to some/many site owners.

And then in #2455081: [policy, no patch] 8.1.x release schedule I proposed that we open 8.2.x-dev as soon as 8.1.0-beta1 is tagged if the technical debt is manageable, and so on. I think the combination of those two suggestions would help balance the two "competing goals" listed in the summary. That way, there are no more long freezes without feature development unless we specifically delay opening a dev branch due to technical debt (which would have a similar effect to the "slushes" for issue thresholds early in the 8.x cycle before it got out of control and without the count-based incentive for playing shell games of technical debt).

xjm’s picture

Actually, re-reading @effulgentsia's post:
"However, since then, Symfony decided on releasing a 2.8 LTS on the same day as 3.0..."

Isn't 2.8 the forward-compatible release with all the deprecated stuff removed? So both 2.7 and 2.8 are LTSes, but 2.8 has less crufty stuff? I thought that's what @alexpott described, but I looked in http://symfony.com/doc/master/contributing/community/releases.html and it doesn't seem to say anything about that.

Also related: #2607260: Remove deprecated code USAGES before 9.x is opened for development (retaining the deprecated APIs)

xjm’s picture

alexpott’s picture

I misunderstood @fabpot's talk in Drupalcon Los Angeles. Symfony 2.8 will contain all the new features of Symfony 3.0 but Symfony 3.0 will have all the deprecated code from the Symfony 2 cycle removed. Which makes complete sense since doing anything else would break semver.

xjm’s picture

Issue summary: View changes
FileSize
24.58 KB
25.64 KB

References for #18:

http://symfony.com/blog/transition-from-symfony-2-7-to-3-0-symfony-2-8-o...
https://www.symfony.fi/entry/november-2015-php-7-0-0-symfony3-ez-platfor...

So what it sounds like is that feature and API additions go into 2.8.x and 3.0.x, and 3.0.x is the future-compatible branch (not 2.8.x). Meaning, if we applied this to Drupal, 9.0.x would contain the same features as the LTS (say 8.5.x), but break BC. (The second part of what Symfony does is that both 2.8.x and 3.0.x are LTSes, but I think we did not want to do that for Drupal; it would mean supporting 8.0.x until 9.0.0 is released.)

To compare these two options (LTS ASAP after 9.x dev opens, vs. LTS on the day 9.0.0 is released), I updated the current release cycle diagram. In both cases the diagram has 9.0.x development started 18 months-ish after 8.0.0, and 10.0.x started more quickly, 10 months or so after 9.0.0. A result would be an additional minor of 8.x, which also seems more realistic to me.

Original schedule: LTS immediately after 9.0.x-dev

Proposed modification (more like Symfony): LTS concurrently with 9.0.0

Edit: note that the D7 LTS time here is non-canonical; I'm only looking at the D8/9/... LTS.

xjm’s picture

Issue summary: View changes

So, there are actually several different questions to set for this issue and #2608496: [policy, no patch] Drupal 7 (and 8) EOL timing. I added a list to the summary.

xjm’s picture

Issue summary: View changes

...Reordering them to put the questions for the other issue last.
And finally, my preferences on each question:

  1. D7 LTS should start once the D7/8 migration path is fully supported.
  2. D7 LTS should end once D8 LTS begins, same as the current policy. This is essential for LTSes to meet the need they're intended for.
  3. D8 LTS should be released at the same time as 9.0.0.
  4. D8 LTS should end once D9 LTS begins.
xjm’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes

Added #21 to the issue summary, since I agree with that as a proposal.

David_Rothstein’s picture

D7 LTS should start once the D7/8 migration path is fully supported.

What does "fully supported" mean in this context?

So I think it would make more sense to talk about a time after which we put an extra focus on stability (and calling that an "LTS"), but that doesn't mean we can't add new features during that time period if people want to add them. It just means we get much more strict about backwards compatibility and put the brakes on any features that don't meet those requirements.

Here are some examples of what I meant by the above:

  1. #606598: Human readable image-style names - would not have added this during an LTS (too risky)
  2. #1209532: Count node views via AJAX in the statistics module - I think it would be fine to add something like this during an LTS, since it's opt-in and essentially zero risk to existing sites

Note that there are a lot of different definitions of "LTS" out there in the wild. Ubuntu for example says they will add certain features during an LTS, although it's not the main priority (https://wiki.ubuntu.com/LTS). Other definitions are much closer to "security fixes only", but for Drupal we seem to be trying to define that as a separate phase.

catch’s picture

What does "fully supported" mean in this context?

It would mean:

- migrate UI in core and not experimental
- Drupal 7 migration available in the migrate UI (assumes that all sub-issues of #2456259: [META] Drupal 7 to Drupal 8 Migration path are fixed.)

David_Rothstein’s picture

So we reached that level of support for D6=>D7 the day 7.0 was released, but many sites could not really upgrade to Drupal 7 for years after that (mostly due to contrib upgrades not being in place, but also due to bugs in the core upgrade path that weren't found until the system had gotten more real-world testing). Some people are still saying they can't.

There's a definite risk the same thing will happen for D7 => D8 (plus the cost of a migration will be expensive for many sites either way) so we need to take that into account.

I think in order to make the best decision, we need to see how 8.0.0 adoption and D6 and D7 migrations go, and to see how minors work out.

Yes, maybe we could even officially postpone this issue until a little later.

catch’s picture

So we reached that level of support for D6=>D7 the day 7.0 was released, but many sites could not really upgrade to Drupal 7 for years after that (mostly due to contrib upgrades not being in place, but also due to bugs in the core upgrade path that weren't found until the system had gotten more real-world testing).

Well it wasn't just the issues being found, it was them not getting fixed. These are what I think the real reasons were:

- #895014: All fields of a node type are lost on module disable against 6.x was supposed to block the 7.0 release, but never did.
- #1017672: D6 to D7 update process permanently deletes comment bodies and other data, and throws fatal SQL errors (a different fix for the same root bug) took more than 6 months to get committed, despite being critical
- 8.x was opened at DrupalCon Chicago despite the 6-7 upgrade path being a mess
- CCK and Views upgrade paths were both in contrib, despite fields moving into core,
- it was nearly impossible to get patches committed to 7.x at all for about 6 months - because 7. de-facto went into 'security fixes only' mode almost immediately, even if it eventually came out of it again.

None of the problems with the 6-7 upgrade path were because 6.x core development slowed down.

drush and core experimental UI support for 7-8 should mean we get some real world testing before official support happens too - whereas with 7.0 the release was more or less as soon as we had a 6-7 upgrade path at all, due to it being the last chunk of critical issues before RC.

catch’s picture

I'm not sure if I'd just not noticed before, or if they've changed it, but the first 3.x LTS for Symfony is going to be 3.4, not 3.3: http://symfony.com/roadmap#checker

That means November 2017, supported until November 2021 for security, and they're apparently not going to go past that in the 3.x series.

That then leaves us with three options, unless something changes:

- move 8.x to Symfony 4.* eventually (if that's feasible when it comes out)

- aim to end security support for the 8.x LTS release in November 2021

- keep supporting the Symfony 3.* components we use for security beyond Symfony's own support cycle

dawehner’s picture

Interesting problem. Now its 2015, and I kinda hope that we don't spend more than 3 years on each major release again, this is just not sustainable.

Given that the update to symfony 3 is not super crazy painfull I think moving to symfony 4 if still needed is a reasonable goal.

catch’s picture

Further to that, the LTS release of Symfony 4 is 4.4, released in November 2019. Any 4.* releases prior to 4.4 won't be supported as long as 3.4 is.

catch’s picture

Interesting problem. Now its 2015, and I kinda hope that we don't spend more than 3 years on each major release again, this is just not sustainable.

Well it comes down to when those years are spent. I could easily see us not opening the 9.x branch for at least another 18-24 months.

However for me at least, it would be great to go from branch opening to release within 6-12 months for 9.x.

After 9.0.0, we might not open the 10.x branch for 18-24 months again.

If something like that happens, we're still spending 3 years on each major release, but it's one year before and two years after the first tagged stable release.

#2608062: [policy, no patch] Pre-requisites for opening Drupal 9 is open for some of that discussion.

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.

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.

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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

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