[policy] Decide how long major Drupal versions should be supported

In general, big +1 for this. We already have a consistent release schedule for minors but this provides a consistent release schedule for major versions, similar to other major open source projects, and aligning ourselves with Symfony makes perfect sense.

As I said in the other issue one benefit of this over the other suggested approaches is that as well as the LTS to LTS upgrade path every two years, complex sites can even choose to do two major version upgrades in quick succession every 4 years if they want to; they can go from Drupal 10.4 to 11.4 to 12.0, and then only have to do minor upgrades from 12.0 to 12.4, and then wait again until Drupal 13.4/14.0 for their next major upgrade if they like.

We are always supporting two major versions - although this doesn't seem to have been a huge problem in the 9.x cycle - but we now have a short window where we are supporting a third major, which means more work for the security team and release managers.

While Symfony should be consistent, we are also assuming that none of our other dependencies will go EOL in the same time frame. There's a chance we pick a dependency that we ship with Drupal 10.0, but it is deprecated in the 10.x cycle and goes EOL before Drupal 11.4 is out. We will just have to handle this case if and when it happens.

In general, big +1 for this.

Fully agree with @longwave! Big +1 from me too.

General +1 to this, I've been thinking exactly the same way with Symfony 6 becoming a real possibility, but had not been able to sit down properly to write it up yet, so glad effulgentsia is doing it :)

Apart from the potential for a longer LTS, and us not getting as squeezed ourselves by Symfony EOL dates, having a stable and predictable time between major releases seems like the best way for both contrib and sites to keep up with us.

Also release the prior major version's LTS release at that same time (same as what we did for Drupal 8 and will do for Drupal 9).

If we can reduce the amount of 'last minor' work we have to do each major (cross-major-version module compatibility in Drupal 8, a stable ckeditor5 module in Drupal 9, many more things), then I think we should consider staggering the LTS and new major releases by around three months. This would still be three months after Symfony's new major version (and the PHP release we absolutely need to be compatible with) comes out, so enough time to finalise compatibility changes with both before things go LTS, as we're doing currently with Symfony 5.4 and PHP 8.1 - with both looking very feasible well in advance.

There are three advantages to this:

1. Contrib get a three month window where there is a final set of deprecations, in order to get compatible with the new major before it actually comes out.

2. Sites get three months to update to the LTS release, encouraging a smaller hop to the new major (as we recommended with going 8.9 to 9 where possible).

3. However the biggest advantage is this would allow us to provide a six month LTS overlap without extending the EOL date or having any extra releases. - Bringing the first LTS release 3 months earlier means double the window for LTS-to-LTS sites to do the upgrade between fully supported releases.

However being able to do that, means being on top of all of those things earlier in the release cycles so we're not filling up the last minor release with them.

While Symfony should be consistent, we are also assuming that none of our other dependencies will go EOL in the same time frame. There's a chance we pick a dependency that we ship with Drupal 10.0, but it is deprecated in the 10.x cycle and goes EOL before Drupal 11.4 is out. We will just have to handle this case if and when it happens.

This worries me as well, see some more discussion of this problem in #3173787-26: [policy] Require PHP 8.1 for Drupal 10.0 if a dependency does, otherwise require PHP 8.0. (up from 7.3 in Drupal 9). Also older discussion in #2899825: Release and support cycles for PHP dependencies. When we run into stuff like this, as we have a bit with Doctrine where half the stuff we're using is abandoned already, it's really a sign that it shouldn't be a dependency any more.

General +1 to this too.

When we run into stuff like this, as we have a bit with Doctrine where half the stuff we're using is abandoned already, it's really a sign that it shouldn't be a dependency any more

Agree, at that point forking is no lesser an evil than running abandoned code. At least we can maintain it if its forked.

+1 to the proposal but with a less aggressive php support: Not the latest but the version before that. (8.0 for 10, 8.2 for 11)

I agree that a php version should be supported throughout the full release period, but jumping on a new php version within 6 months of its release is not always possible.

I often use Fedora, which is known to be aggressive with updating its packages, but iirc php 8 is still not supported in a stable release. It will be supported in Fedora 35 releasing end of October, almost a year after the release of php 9.0

For those using Ubuntu, it will also be defaulting to 8.0 in the october release.

Ubuntu also has its LTS releases in the even years (the same as proposed drupal major releases), so they could fall nicely for the original proposal, or if the current delay in adopting 8.0 is expected, 22.04 LTS might remain on 8.0, 24.04 on 8.2 etc.

Centos/RHEL are longer releases but they provide multiple versions of php.

Debian latest release is on 7.4 so it will still require a custom php package.

Beginning with Drupal 11.3, allow more dependency updates into the X.3 release than we allow for other minor releases. In particular, re-raise the PHP minimum to the new 2nd-to-latest version, and allow major updates of non-Symfony dependencies to the extent that these aren't too disruptive (as determined by Drupal's release managers).

This works against one benefit of the longer LTS, which also isn't mentioned in the issue summary yet. No time to update properly now but will try to later.

A new site launched on 9.0.0 will have almost exactly 2.5 years before it needs to do a major update.

A new site launched on 10.0.0 will get approximately 4 years and 3 months, after which it could go LTS to LTS

If we make 10.3 intentionally disruptive, then the advantages of being on a single major release for a longer period are diminished.

Additionally, raising PHP version half way through a major release seems like it will increase the likelihood of contrib modules not being compatible with that new release (vs. if they're developed with compatibility in mind in the first place, or updated as part of a major Drupal version update), and then sites could end up stuck on a minor release which has a much shorter security cycle.

So it feels like trading some sites being stuck on the LTS (not much of a problem from Drupal 10 onwards since the LTS will last longer), for sites potentially getting stuck on a minor (quite a big problem and one we had a couple of times with Drupal 8 whether due to dependency updates or upgrade path bugs).

I like the proposal as it is now in the IS. There is only one thing I would like to change and that is the PHP version with which a new major versions are released. For Drupal 10 will that be PHP 8.0 and to me that is right, because Drupal 9 will be EOL in 12 to 18 months after the release of Drupal 10. Every major release after Drupal 10 will get the PHP version that is the 2nd-to-latest version. That version will be at least 18 months old, when the new major version is released. To me, we could do better and set it to the latest version. For developers will that much more exiting. We would like to attract new developers and working with older software versions is to them less exiting then the working with the newest stuff.

Something went wrong with posting my reply

In general, I love this proposal. I agree with @daffie:

very major release after Drupal 10 will get the PHP version that is the 2nd-to-latest version. That version will be at least 18 months old, when the new major version is released. To me, we could do better and set it to the latest version.

I agree. The issue summary says:

For Drupal 10, support this PHP version for the lifetime of Drupal 10. This means supporting PHP 8.0 in Drupal 10.4 until September 2026, which will be almost 3 years past PHP 8.0's EOL, just like we're currently supporting PHP 7.0 in Drupal 8.9 even though it's now almost 3 years past PHP 7.0's EOL.

We are so careful to avoid EOL dependencies, but happily supprt three years of and EOL PHP? I think we should bump to latest PHP release. Its OK if not everyone can adopt 10.0 on day one. If sites wait until 10.1 or 10.2, that’s totally fine.

I also think we should release with the more recent PHP release rather than supporting the older one an extra year beyond its EOL date.

I've added an alternate for the PHP policy to the issue summary.

> Although Symfony provides a consistent release cycle and long LTS releases (their prior major versions are supported for 4 years following the release of a new major version), many of Drupal's other dependencies do not. Currently, our policy is to not update the major version of a dependency within a major version of Drupal, but this makes it hard to support a given Drupal major version for say 4 years or more unless we change that policy.

What's the reason for not saying that some of our dependencies are considered internal to Drupal? If that were the case, we'd be free to change the versions of these whenever is convenient.

What's the reason for not saying that some of our dependencies are considered internal to Drupal?

There are broadly two reasons:

1. If we drop older versions of dependencies altogether, contrib modules explicitly depending on those older versions become incompatible with core. So ideally we'd allow but not require newer versions. But this requires #2874198: Create and run dependency regression tests for core to be able to do that reliably.

2. Some of our dependencies are exposed as public APIs via Drupal. Guzzle is an obvious one, since it's the http client, although we've considered updating to Guzzle 7 in Drupal 9 due to their policy not to actively support PHP 8 or 8.1 in Guzzle 6 (see #3104353: Upgrade to Guzzle 7 and elsewhere), and because the changes from Guzzle 6 to 7 would probably be transparent to most uses. However we haven't needed to yet. But if Guzzle 7 contained significant changes, then updating to that would change Drupal's public API too. An example where we've had trouble with even minor releases of dependencies is Symfony validator: #3054535: Discuss whether to decouple from Symfony Validator. If core is able to adapt to both versions easily though, then we're left with the testing issue from #1.

I think there's broad consensus here, what's the next step?

I think there's enough framework managers in this issue to remove that tag

The problems that we now have with Guzzle 6 are because we want to support PHP 8.1. It is something we should do, but for me only for the Drupal core version that is in active development. For Drupal core versions that are no longer in active development and are not EOL, I think we should consider NOT supporting PHP version that are released after Drupal core leaves active development.

Say that D10 is released next summer and in PHP 8.2 is something that is very difficult to support in D9, than we should sorry, but PHP 8.2 is not supported on D9. If we can easily support PHP 8.2 on D9 than we should do it, only we have the option to say NO. At that point we should say that if you to use the newest version of PHP than you must also use the newest version of Drupal core, which at that point would be D10.

The policy for me would be: that all PHP version will be supported by Drupal core as long as the version is in active development, after it leaves active development it is up to the release manager to decide if a newer PHP will get supported on the "older" Drupal core version. When we easily can do it than we will, when we run into problems with for instance dependencies versions that do not support the newer PHP version than we will not.

Edit: Maybe we should the same for newer database version.

Say that D10 is released next summer and in PHP 8.2 is something that is very difficult to support in D9, than we should sorry, but PHP 8.2 is not supported on D9. If we can easily support PHP 8.2 on D9 than we should do it, only we have the option to say NO. At that point we should say that if you to use the newest version of PHP than you must also use the newest version of Drupal core, which at that point would be D10.

This is the case for the 8.x LTS currently too - Drupal 8.9 supports PHP 7.4, but it doesn't support any PHP 8 versions. Once we get to LTS, we don't want to update dependencies in the same way we don't want to backport too many core patches either.

The problem is if we run into a dependency that has an EOL (not just LTS minimal-maintenance release) shorter than the Symfony version we're on. So far this hasn't really been an issue for us, but it's possible.

Regardless of which PHP version policy we went for, I'd go for #23.2 - i.e. increasing the maximum version in composer.json, and only increasing the minimum if there's an SA. The main issue with #23.2 is we can't do it yet.

How would that work? For example, let's say at the time that we release Drupal 10, Guzzle 7 is the latest major version. But let's say 3 months later Guzzle 8 is out. In the case of Guzzle, they promise 2 years of security support for the N-1 version, so that would mean 10.4.0 could still include ^7 || ^8 if we want it to, but at some point during 10.4's lifetime, an SA might go out on Guzzle 8 that's not backported to Guzzle 7. Is the suggestion that if this happens, then in a patch release of 10.4, we bump up the composer.json requirement to ^8

I think in that scenario we might have to fork Guzzle and backport ourselves. This is not disimilar to how Ubuntu run their LTS right - they backport to unsupported PHP versions.

Are we sure we can take on that burden?

Which I guess is the crux of the remaining debate here.

Personally I think the effort is worth it, it gives site owners a lot of certainty and removes a lot of the churn. From 'I have to update every 12 months to stay in security support' to 'I have to update every 2 (and a half) years'.

But let's say 3 months later Guzzle 8 is out. In the case of Guzzle, they promise 2 years of security support for the N-1 version, so that would mean 10.4.0 could still include ^7 || ^8 if we want it to, but at some point during 10.4's lifetime, an SA might go out on Guzzle 8 that's not backported to Guzzle 7. Is the suggestion that if this happens, then in a patch release of 10.4, we bump up the composer.json requirement to ^8? As opposed to having done that in either 10.4.0 or an earlier minor release? The up side of that is then we potentially get away with not having to bump up the requirement at all if the EOL dependency never has an SA that's needed. But the down side is that if an SA is needed, then it's a very disruptive change to release in a patch/security release.

I think we'd have to do the same as we do for other disruptive changes that are necessary for security and fixing critical bugs - look at whether raising the minimum will actually cause disruption, and if it does then backport the change, but with the option to raise the minimum if it's fine. We've already shimmed Guzzle 6 for PHP 8 support, and while it was slightly annoying it was very simple to do in the end.

With all of our dependencies, only Symfony has a defined EOL date - all of the others have irregular release schedules, and support the previous version on a best-effort basis (probably until it becomes hard to do so, or they think no-one is using it any more). We've already opened github issues with Guzzle about their EOL plans, and they've been very transparent. https://github.com/guzzle/guzzle/issues/2358. In this case the answer was 'we'll try to support it until your EOL, but we can't promise anything'. So in general we're not going to get a date when the older version is out of support, we'll get a new version, and one day something will come along and the old version won't support it (most likely a newer PHP version, but potentially an SA). This means if we do a straight switch between major versions of a dependency when the new one comes out (or x.3.x), we'd be dropping support for the old one potentially years before it's actually EOL.

A closer example (although without the SA) is what we've had to do with Doctrine in 9.3: #3180351: doctrine/reflection is abandoned, where they completely abandoned code we're relying on, so we had to fork it into core. If we have a dependency where their release/support schedule is clearly incompatible with core's release schedule, then we either need to ask them to extend the EOL for us, or fork/replace anyway.

It's definitely a trade-off between 'take a risk that something very annoying happens, but hope that it doesn't', vs. 'introduce a disruptive change early to avoid the risk of having to do so later', but I feel like allowing more recent versions (and potentially warning about older versions in hook_requirements()) bridges that a bit.

Here's an image that shows the key dates - I promoted this issue in my presentation at DrupalSouth shorts 2021. Hopefully that drives some more conversation here.

I've removed this from the issue summary, reasoning follows below.

Because X.LAST is released around the same time as (X+1).0, an X.LAST to (X+1).LAST overlap also implies an X.LAST to (X+2).0 overlap, which would give site owners the option to skip major versions entirely. For example, this proposal would enable a site owner to go from 10.LAST to 12.0, then do minor updates to 12.LAST, then go to 14.0, etc. For site owners for whom minor updates are easy and major upgrades are hard, this doubles the lifetime they get from each major version.

In terms of raw timing yes, but in practice, this is currently impossible and would be extremely hard to make possible.

We removed hook_update_N() added between 8.0.0 and 8.7.0 in Drupal 9, so that sites would have to update from 8.8 or 8.9 first, and only from there to 9.x. There's an issue to do the equivalent for Drupal 9 to 10 too. This means you can go from 8.9 to 9.4 (LTS to LTS), but not 8.0 to 9.0 or 8.9 to 10.0.

This was to reduce the likelihood of obscure upgrade path bugs from trying to skip multiple minor versions straight to a new major (since the more updates run all in one go, the more likely there are to be conflicts or dependency issues between them). And also to encourage people to update contributed modules with their 8.8/8.9 core updates, instead of all at once with Drupal 9.

This has been a success - no complaints about not being able to jump from <= 8.7, and very few obscure upgrade path bugs to Drupal 9 (possibly none against core at all, compared to loads in Drupal 8 minors). We also had a moratorium on new upgrade paths in Drupal 9.0 for the same reason, to make the hop between majors as small as possible.

Most contrib modules have made their modules 8 || 9 compatible instead of jumping to >= 9, but from personal experience, modules that did Drupal 9 compatibility and simultaneously dropped Drupal 8 support have been a complete pain to deal with. It eliminates the possibility to do that pre-major-update step and just update core in isolation.

While it's reasonable to ask contrib to support ^8.8 || ^9, we can't reasonably expect all contrib modules to maintain a single version of their module compatible with three major releases of Drupal core. If you have a module that is using APIs deprecated in Drupal 9, then to make it Drupal 10 compatible, you have to drop support for Drupal 8. Some will be fine and work across all three, some won't.

On top of this, Drupal 10 LTS and 12.0 may not even share a common PHP version - it depends at what point we're unable to support newer PHP versions after Drupal 10's release. For example Drupal 8.9 doesn't support PHP 8, but Drupal 10 will require it. So you're then looking at an infrastructure upgrade in the same window as a core + contrib update.

I think it's worth comparing this to other possible regular release cycles that tie-in to Symfony's.

For example we could release every four years, always skipping a Symfony major release.

Advantages: individual release lifecycle is the longest possible (a year longer than the proposal) meaning individual sites, contrib modules etc. get to stay on it for the maximum amount of time.

Disadvantages: less then 18 months for contrib and sites to update between majors, jumping a Symfony release is an unknown amount of disruption until we actually try it each time, every site has to follow Symfony minor releases, we'll build up more overall technical debt during a cycle.

Looks like this:

Drupal 10 on Symfony 6 - June 2022, EOL Nov 2027

Drupal 11 on Symfony 8 - June 2026, EOL Nov 2031

Drupal 12 on Symfony 10 - June 2030, EOL Nov 2034

(S6: Nov 2021-Nov 2027
S7: Nov 2023-Nov 2029
S8: Nov 2025-Nov 2031)

@catch: I get why we be better of with a longer release cycle. It is better for the site owners. Only we have changed Drupal to use a lot of dependencies and those dependencies are doing the shorter release cycle thing. This will create problems for Drupal with having to jump to a new major version for a dependency without Drupal creating a new major release.
The problem for me is that the rest of the PHP community is doing the shorter release cycle thing and the sensible thing is to do the same. Just follow Symfony with their 2 year release cycle and do a new major release about 6 to 9 months after Symfony does their new major release. Also skipping a Symfony major release is not making me very happy.

@daffie yes that's why my list of disadvantages was much longer than the advantages, but it's worth thinking through.

but it's worth thinking through

You are absolutely right about that!

My observation is this: it generally takes up to 2 years for major contrib modules to be fully compatible with a new Drupal major release, but also about that time for the major release itself to become coherent, stable and robust.
Except for the simplest things, 8.0.0 was unusable when it was released, partly due to lack of contrib, but also because of bugs and catch-22s within the release.
In general, it's not wise to upgrade until the major release has reached version x.3 or x.4

Longer release cycles aren't only better for site owners, but also for their webmasters.
I can't justify pushing site owners/clients to upgrade to a new major version every 2 to 3 years, especially when there is a lot of custom code that needs to be adapted.

Drupal should not be a slave to external dependencies. Symphony has a laughably short lifecycle: https://endoflife.date/symfony
This is madness and not sustainable, and will cause abandonment and forks (backdrop & co.)

But I see why keeping up with Symphony makes sense.
Therefore Drupal should make its major releases compatible with at least 2 major releases of Symphony and offer at least 5 years lifecycle for every major release.

Drupal 9 for example, should be made compatible with Symphony 5.x to achieve end of life 30th Nov 2025.
We know that it's possible, because Drupal 7 has been extended until 2023 as a slap in the face of every webmaster that has been pushing clients to upgrade.
The reason is probably because Drupal.org is still running "lots of custom code" on Drupal 7 and probably plans to upgrade directly to Drupal 10, so people who installed Drupal 8 and 9 are out of luck ! that's fair. as if sites using Drupal 8 didn't have "lots of custom code".

Anyway, I agree with catch's proposal above

Drupal 10 release in 2022, EOL 2028 (end of security support)
Drupal 11 release in 2025, EOL 2031 (end of security support)

Shorter cycles would place Drupal webmasters and clients under duress.

Drupal 9 for example, should be made compatible with Symphony 5.x to achieve end of life 30th Nov 2025.

I am not sure if it is possible. Lets find out. I have created #3266252: [policy] Release a Drupal 9.10 that uses Symfony 5.4 and CKEditor 5, and is supported until 2024 for it.

@manarak: Thank you for your input. It is much appreciated.

My observation is this: it generally takes up to 2 years for major contrib modules to be fully compatible with a new Drupal major release, but also about that time for the major release itself to become coherent, stable and robust.
Except for the simplest things, 8.0.0 was unusable when it was released, partly due to lack of contrib, but also because of bugs and catch-22s within the release.
In general, it's not wise to upgrade until the major release has reached version x.3 or x.4

This was true for Drupal 6, Drupal 7, and Drupal 8, but it wasn't true for Drupal 9 because we completely changed the release cycle.

Up to Drupal 6, major release cycles were more like 6 months to a year, with much less changes each time, but also there was a much smaller install base of existing sites to actually get upgraded at least until around Drupal 5/6.

This is not to say there were zero issues between Drupal 8 and Drupal 9 - it took some contrib modules a lot of time to declare Drupal 9 compatibility, even if the declaration was the only thing they needed to do, but that issue is further being improved from Drupal 9 to 10 and I would expect it to get easier again between Drupal 10 and 11.

Drupal 9 for example, should be made compatible with Symphony 5.x to achieve end of life 30th Nov 2025.

ckeditor4 end of life is the end of 2023. Even though we can ship ckeditor5 support in 9.4, we can't remove ckeditor4 from it.

There are multiple issues around to allow core support for multiple major versions of dependencies, but they're quite blocked unfortunately, see #3020303: Consider using Symfony flex to allow switching between major Symfony versions and #2874198: Create and run dependency regression tests for core.

Drupal 10 release in 2022, EOL 2028 (end of security support)
Drupal 11 release in 2025, EOL 2031 (end of security support)

I think a date might have got switched around here - this isn't from the issue summary, nor from my comment above.

@catch

I shifted Drupal 10 end of life to 2028 because I expected Symphony 6.4 to have security support until 2028, but I just checked here:
https://symfony.com/releases/6.4
and it's indeed 2027. my mistake.
So Drupal 10 should go EOL in 2027 as you correctly wrote.

ckeditor4 end of life is the end of 2023. Even though we can ship ckeditor5 support in 9.4, we can't remove ckeditor4 from it.

Yes, there are probably other dependencies to consider, but IMO Drupal should give its users breathing time and commit to a regular cycle that guarantees that a major release *as well as major contrib modules" are usable for at least 3 years.

I'm not very knowledgable about CKeditor, but if it can be done, your proposal of shipping Drupal 9.4 with both versions seems to be a good compromise? Then site admins could make the switch to CKeditor 5 in the site configuration?

This is not to say there were zero issues between Drupal 8 and Drupal 9 - it took some contrib modules a lot of time to declare Drupal 9 compatibility, even if the declaration was the only thing they needed to do, but that issue is further being improved from Drupal 9 to 10 and I would expect it to get easier again between Drupal 10 and 11.

hopefully.
but this is just expectation.
my reality at the moment is that I'm still busy upgrading sites from D7 and D8 to D9. Ironically, I started work on D7 because it seemed more urgent. now my clients' D8 sites are EOL, while D7 has been extended :-/

from my perspective as a sitebuilder, another main concern is with contrib and core features.

Drupal core is not adapting fast enough to requirements in website technology - up to date features are provided by contrib.

I try to build fast websites with 0 CLS, and this supposes true responsive images, usage of webp, usage of CSS aspect ratio, as well as true responsive videos (switching size depending on client device type / viewport), webm using vp9, correct use of lazy-load or eager in the right places, and caching of anonymous pages depending on client device type. This all while scoring 100/100/100/100 in lighthouse.

It's not possible to achieve this with Drupal core alone or using just larger contrib modules counting 20k+ users.
I have to use a combination of custom code and some obscure contrib modules.
Some of these *CRITICAL* contrib modules are maintained by just 1 maintainer, some have just a couple thousand users or less, and the CSS aspect ratio module is *SANDBOX*.

And as I'm mainly into making multilingual websites, I use a myriad of other language and SEO-related modules. My composer.json's require section is already 80 lines long for a static site.
I plan making sites centered on user-generated content soon, and I guess the number of contrib modules might grow by 50% to 120 or even double to 160.

So my websites stand on wobbly legs.
Contrib is absolutely critical.

That's why faster release cycles are poison for me, and I think many sit in the same boat.

* looks to Drupal.org, still running on D7 *

and it's indeed 2027. my mistake.

There's also no suggestion in either the issue summary or my comment to release Drupal 11 in 2025. The possibilities suggested were 2024 in the issue summary, or 2026 in my comment.

I'm not very knowledgable about CKeditor, but if it can be done, your proposal of shipping Drupal 9.4 with both versions seems to be a good compromise? Then site admins could make the switch to CKeditor 5 in the site configuration?

Then according to your proposal of extending Drupal 9's EOL beyond ckeditor4's, we'd be knowingly shipping code with unfixed public security vulnerabilities for approximately two years.

commit to a regular cycle that guarantees that a major release *as well as major contrib modules" are usable for at least 3 years.

The issue summary is suggesting a regular release cycle, with a lifetime for each release of more than 4 years.

Thanks for sharing @manarak, that's really valuable info. If it's not too much to ask, perhaps you could group the modules you use in three groups, like "Crucial", "Important" and "Nice to have" and post the list in the forum?

In that way, me and others can give them the extra attention they need to gain more traction and usage.

@catch
about the transition of CKeditor from 4 to 5, how about retiring CK4 from Drupal 9 distribution, and providing it a separate "at your own risk" module.
there are plenty of vulnerabilities that are very limited in scope or with very limited damage potential and depend on specific usage / specific html tags.
it's up to site admins if they want to downgrade CKeditor and up to them how they protect their website if they do it.

there are also many site that don't use CKeditor at all, why should they be forced to upgrade?

@ressa
heres what I have so far as "critical modules"
your definition of "critical" may vary.
"critical" for me, means without these modules I won't be able to fulfil my client's wishes within acceptable cost and time.
this is for static sites with no user generated content

"bower-asset/lazysizes": "5.1",
"composer/installers": "^1.9",
"cweagans/composer-patches": "^1.7",
"drupal/admin_toolbar": "^3.0",
"drupal/advagg": "^4.1",
"drupal/antibot": "^1.4",
"drupal/classy_paragraphs": "^1.0@beta",
"drupal/colorbox": "^1.7",
"drupal/context": "^4.0",
"drupal/core-composer-scaffold": "^9.2",
"drupal/core-project-message": "^9.2",
"drupal/core-recommended": "^9.2",
"drupal/css_aspect_ratio": "1.x-dev",
"drupal/d8w3css": "^2.0",
"drupal/devel": "^4.1",
"drupal/entity": "^1.2",
"drupal/entity_browser": "^2.6",
"drupal/entity_clone": "^1.0@beta",
"drupal/entity_embed": "^1.1",
"drupal/entity_type_clone": "^1.7",
"drupal/entity_update": "^2.0@RC",
"drupal/entity_usage": "^2.0@beta",
"drupal/field_group": "^3.2",
"drupal/filefield_paths": "^1.x-dev@dev",
"drupal/flexslider": "^2.0",
"drupal/honeypot": "^2.0",
"drupal/hreflang": "^1.4",
"drupal/imageapi_optimize_binaries": "dev-1.x",
"drupal/imageapi_optimize_webp": "dev-2.x",
"drupal/lazy": "^3.0",
"drupal/menu_block": "^1.7",
"drupal/menu_link_attributes": "^1.2",
"drupal/metatag": "^1.16",
"drupal/mobile_detect": "^3.0",
"drupal/paragraph_view_mode": "^2.0",
"drupal/paragraphs": "^1.12",
"drupal/pathauto": "^1.8",
"drupal/rules": "dev-3.x",
"drupal/token": "^1.9",
"drupal/twig_tweak": "^3.1",
"drupal/webform": "^6.0",
"drupal/xmlsitemap": "^1.0",
"jackmoore/colorbox": "^1.6",
"oomphinc/composer-installers-extender": "2.0",
"wikimedia/composer-merge-plugin": "^2.0",
"woothemes/flexslider": "~2.0"

in addition, I have the following "nice to have" modules. clearly, some are way more useful than others:
"drupal/animate_css": "^2.0",
"drupal/asset_injector": "^2.8",
"drupal/back_to_top": "^2.0",
"drupal/backup_migrate": "^5.0",
"drupal/bg_img_field": "1.7",
"drupal/block_class": "^1.3",
"drupal/critical_css": "^1.17",
"drupal/diff": "^1.0",
"drupal/dropdown_language": "^3.0",
"drupal/editor_advanced_link": "^2.0",
"drupal/google_analytics": "^4.0",
"drupal/layout_paragraphs": "2.0.0-beta6@beta",
"drupal/media_directories": "^2.1",
"drupal/menu_breadcrumb": "^1.16",
"drupal/permissions_by_term": "^3.1",
"drupal/rabbit_hole": "1.0-beta10",
"drupal/recaptcha": "^3.0",
"drupal/redirect": "^1.6",
"drupal/responsive_favicons": "^1.6",
"drupal/schema_metatag": "^2.2",
"drupal/search_api": "^1.20",
"drupal/search_api_db": "^1.20",
"drupal/seo_checklist": "^5.1",
"drupal/sidr": "^4.x-dev@dev",
"drupal/superfish": "^1.4",
"drupal/toolbar_language_switcher": "^2.0@alpha",
"drupal/twig_debugger": "^1.1",
"drupal/typed_data": "dev-1.x",
"drupal/unmanaged_files": "^1.0",
"drupal/views_blogspot_archive": "^1.4",
"drupal/views_bulk_operations": "^4.0",
"drupal/views_conditional": "^1.4",
"drupal/views_contextual_filters_or": "^1.2",
"drupal/w3css_paragraphs": "^1.0.2",
"drupal/yoast_seo": "^1.7",

still, just for static sites

I expect the above list to grow by 50% if I build a site around user-generated content.

@catch
about the transition of CKeditor from 4 to 5, how about retiring CK4 from Drupal 9 distribution, and providing it a separate "at your own risk" module.

We're going to provide a ckeditor4 module in contrib for 10.x (for sites that want to update to 10.x, then update ckeditor once they're on it), but removing it from core in 9.x would be a hard bc break.

Really if you want to discuss extended Drupal 9 support, please open a new issue, this issue is about trying provide longer support from 10.x onwards.

Not sure if it helps with the discussion, but my situation is almost identical to @manarak and I totally agree with him on all points.

I was able to upgrading my last D8 sites only 2 months ago, because of upgrade issues in contrib modules. Now we're already seeing the 10 alpha the `also available list` and it made me worry a little to be honest.

@rbosscher if you do not like Drupal major updates, then you should plan for LTS to LTS updates.

Adding screenshots from Lee's session that included this at https://www.youtube.com/watch?v=Q8-I-fhVTUg to help visualise it. (Even though the dates are off now for 9.4/9.5/10, the illustration stands).

Minor text updates.

It is my understanding that we can postpone a decision on this until the LAST-1 minor release of Drupal 10 though? At least it does not require any further changes to Drupal 10 itself or the minors prior to LAST-1 I think given the existing decisions of PHP requirements and Symfony versions? We should know a lot more about those dependencies by Drupal 10.LAST-1.

While deciding soon would be great, as far as I see this is a "wait and see what happens to dependencies" situation, so we better agree how long we can / are willing to wait to see which is the decision we seem to be able to make now, rather than comitting to something we don't know if we can achieve yet?

wait and see what happens to dependencies

The problem is only for dependencies and new versions of PHP. It is never with existing PHP versions, because we know that those work or we did not do a release with them. Maybe update the IS with that we support dependencies for 4 years, but only for existing PHP versions with which the Drupal major version was released. For support with newer PHP versions it is only best effort.

For Drupal 10, we will support all dependencies for PHP 8.1. For PHP 8.3 or newer, we just do not know if we can support it. The dependencies are not our own software and we can only hope for the best. We can say that we will do our best, only we do not know what the future might bring.

What we can do is with every minor release of Drupal we can state which newer PHP versions we will support. If some change in PHP 8.x will break the existing (LTS-)version of Drupal, then Drupal will publicly say that that (LTS-)version of Drupal will not work with PHP 8.x.

The problem is only for dependencies and new versions of PHP. It is never with existing PHP versions, because we know that those work or we did not do a release with them.

This isn't always the case though, for example Symfony dropping PHP 8.0 support in Symfony 6.1 - now they did it very carefully and after a lot of consideration, but there's no guarantee that another dependency won't drop PHP 8.1 in 2-3 years in a minor version. We tend to get squeezed from both directions on this with different dependencies and timelines.

so we better agree how long we can / are willing to wait to see which is the decision we seem to be able to make now, rather than comitting to something we don't know if we can achieve yet?

I think this is a good approach - just try to set a date, by which time we should come to a decision, and if we can reach that decision quicker that is good. It's better than not setting a date and also not reaching a decisions.

We could also try to think of 2-3 scenarios that we'll almost certainly end up doing one of (e.g. 2 year release cycle with shorter LTS vs. 2 year release cycle with longer LTS vs. 4 year release cycle skipping symfony majors with shorter LTS) - there are not that many options with the Symfony release schedule, that way at least people know that one of them is very likely.

Has there been any consideration on how an increased cadence for major releases (which traditionally have not contained new features) would impact the frequency of adding new features?

I know that part of the proposed schedule change includes release x.LAST before y.0. Would that mean that y.0 can now include new features? If not, I'm personally concerned about how the proposed changes would impact the ability for for to continue to evolve, not just stay current with dependency releases. Moving to a 24-month major release cycle cycle, if the initial and final releases can't contain new features, would mean a considerable reduction in the ability for Drupal core to continue to weave in new enhancements.

Has there been any consideration on how an increased cadence for major releases (which traditionally have not contained new features) would impact the frequency of adding new features?

So there's not a complete block on features at the moment:
- small features/UX improvements that don't involve upgrade paths or new deprecations can still be committed to 9.5.x
- larger features with new deprecations and upgrade paths can still be committed to 10.1.x

What we're not doing is adding new large features or new experimental modules, especially ones involving deprecations or upgrade paths, to 9.5.x/10.0.x.

There are two main reasons for this:

Workload

So far (not including 8.x which doesn't really count), we've only had two major releases so far, 9.x and 10.x.

For 8.9.x/9.0.x we had a lot of work to do specifically to allow us to make a major release at all: adding deprecation support, allowing modules to work across multiple major versions, all the initial work on drupal rector/upgrade status, sorting out how to support the major upgrade path for actual sites (hook_removed_post_updates() etc.), and a long list of critical upgrade path bugs from previous minor releases (8.3-8.7), as well as large features which had been added to core as unstable modules but weren't stable yet (workspaces).

For 10.x we've skipped a major version of Symfony, have a hard deadline for the end of Symfony 4 support, and have a once a decade-and-half major update of a dependency with massive implications for stored data with ckeditor4-5, also with a hard deadline due to the end of ckeditor4 support.

It looked like jQuery UI was completely going unsupported until a couple of months ago, so there was lots of release-blocking work to decouple core from that, although now that jQuery UI is receiving support again (although we're not sure for how long), some of that is no-longer release blocking and could happen in Drupal 10/11. We've add similar end-of-life and decoupling issues with backbone and underscore (also now partially deferred to Drupal 11 after the most blocking work was done and because there's not a defined EOL yet).

There's also the potential that jQuery 4 will come out soon, so we've been trying to reduce our dependency on jQuery itself to make that update easier, as well as decoupling from backbone and underscore.

And CKEditor5 + jQuery UI + Backbone/Underscore are all heavy JavaScript work, which is where core generally has the least people working on it. Symfony 5 + 6 updates happened incrementally via dozens of contributors over the past 2-3 years, CKEditor5 has been almost entirely a handful of full time developers (on both the CKEditor and Drupal sides). So the fact that various JavaScript dependencies are reaching end of life is having a massive impact - both forcing the release timeline due to EOL dates for dependencies, and also blocking the release itself because of the amount of work to move over.

On top of that we've discovered loads of technical debt relating to removing modules and themes from core - so for example even though Olivero and Claro were marked stable a couple of months ago, we're quite far from being able to deprecate Bartik and Seven - due to migration tests, upgrade path tests, various other core tests that depend on those specific themes, composer/packagist trickiness etc. Some of our jQuery/backbone technical debt is in Quickedit module, which we decided to remove from core rather than refactor in core, and that has been a months-long saga to remove (untested integrations with other core modules + all the above). Drupal 8 didn't remove any production modules in a minor release (that I can remember), so this is another 8+ first to figure out.

Once you add all this up, both major releases so far have had significant unique issues requiring tonnes of work. Trying to introduce new features (either to existing stable modules or as new unstable modules) to the last minor release would just be too much on top of everything else.

The hope would be by increasing the frequency of major releases, we'd be less likely to have a jQuery UI + CKeditor + Backone + Underscore situation all at once. Also due to Drupal 9 having fewer minor releases than Drupal 8, we've accumulated only about 50% of the deprecations to remove, and the few that are left in Drupal 10 are mostly stragglers that weren't done properly in Drupal 8. This also means less deprecations to cover in Drupal Rector and etc.

So if all of that comes together, there would be much less work involved in producing each major release, ideally it'd be more like a 'big minor', and then it'd be possible to fit in feature additions alongside more easily.

However there's also another constraint.

Deprecations/upgrade paths

Even if Drupal 11 was only a couple of straightforward dependency updates and removing deprecated code, we still have to deal with these.

Adding new deprecations in the .LAST minor release for removal in the upcoming major can make it hard to work on major version compatibility for contrib - i.e. there has to be a point long enough before the major release where new deprecations aren't committed. Sometimes we deprecate things for removal in the next major afterwards (9.5.0 for removal in 11.0.0) but our tooling doesn't differentiate, so even if they don't actually affect compatibility, they make it harder to get a clean run with automated tools. We might be able to come up with something for this, but we haven't really yet.

Adding new hook_update_N() adds extra extra potential complexity and sources of bugs for site updates, and can make backports extremely difficult - see #3108658: [policy] Handling update path divergence between 9.5.x and 10.1.x. So we're likely to want to continue minimising those in the .LAST version to as close to zero as possible.

So for example, workspaces, which had to make lots of changes to the Entity API and storage, probably couldn't be introduced in a .LAST release, but something like JSON:API probably could be. And if there's something like workspaces that can't land in .LAST, the development could still happen in the 10.1.x-equivalent branch, so development itself isn't blocked, it's just available for new sites ~6 months later.

I know that part of the proposed schedule change includes release x.LAST before y.0.

This is more about enabling sites to update from LTS to LTS if they want to and wouldn't really impact the above much in any direction.

There's still a lot of unknowns here with things like jQuery, jQuery UI, how we're going to deal with CKEditor 5 updates and security releases in LTSs etc., so I have opened #3330791: [11.x] Policy: target Drupal 11 for 2024 with June/August/December release windows just to talk about getting onto an approximately two year major release cycle and setting some windows for Drupal 11.

Tried to flesh out remaining tasks a bit.

With the rapid pace of major versions in Drupal, upgrade bottle necks happen more often in the contrib space.

Even fairly popular modules installed on hundreds of web sites were quite late to start preparing for Drupal 10 and get a stable release. Some are still not downloadable or installable on Drupal 10, even with Drupal 9 being EOL in six months as of today (May 2023).

Is #3357582: Always allow downloading and installing contrib module dev-release in next major version worth considering?

@ressa
yes, that is a major problem.

Some are still not downloadable or installable on Drupal 10, even with Drupal 9 being EOL in six months as of today (May 2023).

While modules not being ready six months before the EOL makes things very difficult for sites to plan/finish upgrades, it's also the case that with the readiness initiatives more modules are ready quicker after a major release than they ever previously have been. Drupal 6 and Drupal 7 both had several months where top 50 modules weren't available at all. For example Drupal 7.0 was released in January 2011 and Views 7.x-3.0 was released in December 2011.

Modules simultaneously being ready quicker, but also too late for the EOL, is one of the problems we're trying to solve here.

Drupal 5.0 and Drupal 6.0 were released only about year apart. But then Drupal 5, Drupal 6 and Drupal 7 were supported for years after the next major version was released, so it didn't really matter as much how long modules took to get ready for existing sites, more for new sites. What tended to happen was people would use the newest major to build new sites on, modules would gradually get ported for those, and then once the majority had been ported, existing sites on the older major would update too. Right now with only a one year support cycle for the last major, everything is happening at once which feels (and is) rushed.

The problem we have now isn't the frequency of major releases as such, but the short lifespan of each one, and that is what this issue is trying to solve - i.e. Drupal 9 was released in mid-2021 and will be EOL end of 2023, so that's only two and a half years. If we follow this proposal, Drupal 10 will have been released end 2022 and supported until end 2026 which is four years. The end of security support for Symfony 6 is actually end of 2027, so there is a theoretical maximum of five years (except from experience, other dependencies will drop support quicker than Symfony does).

To allow for a 4-5 year support cycle instead of a 2-3 year one though, we need to release the .0 of a major version early on in the support cycle of our own dependencies - i.e. on Symfony 6.1 or Symfony 7.1, not Symfony 6.4 when it's only got 2-3 years left to run, that means a new major every two years.

With D8 we went of the island and start using Symfony. We have been doing major releases with an interval greater than 2 years and now we have the problem that D9 has a very short lifespan. We may not like it, but the rest of the open source PHP world is doing a new major release every 2 years. Therefor I see no other option than doing a new major release every 2 years and having a 4 year livespan for every major release. What the current solution is for this issue. I agree that we shall need to fix the problem of upgrading all the contrib modules every 2 years for the new major release. The obvious solution for me would be to do more with the already created "Automated Drupal 10 compatibility fixes" patches. Can we do a bit more and have them committed automatically and automatically create a new release for the module for the new major Drupal release? To me that would solve the problem.

Thanks for summarizing the situation and task at hand @catch.

I trust that you all here will make the right decisions about upgrade cycles, be they 2 or 4 years, and I am very grateful for all your efforts. They are very much appreciated.

Tremendous work is being done with the Readiness initiatives as well as "Automated Drupal 10 compatibility fixes" patches as you point out @daffie. Yet many contrib modules still lag behind, and we need to solve the recurring problem with the contrib module lag at every upgrade. The upgrade fatigue is real, and a drain on people, making some users tire of using Drupal.

The Drupal Lenient Composer has been released, but I still think recommending relaxing the Drupal core version requirements is a better route: It doesn't require any action from the end user, and lowers the barrier of entry, allowing the contrib module to be installed, as well as get ready well in advance of the next Major release, as discussed in #3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions and #3230209: Remove requirement for core_version_requirement for module to be compatible with Drupal 9.

One thing we might want to consider is to continue doing minor releases of Drupal 10 after Drupal 11 is released, only to update to new minor versions of dependencies and maybe the odd critical bug fix, and for PHP minor version compatibility.

I'm particularly thinking of ckeditor5, but also minor releases of PHP dependencies too. We could support each minor for 12 months or until the Drupal 10 EOL, whichever is the soonest. This adds an extra branch to worry about for security releases, but also means we're much less likely to need to do unplanned updates to dependencies as a result of an SA etc. This is closely tied to #3223443: [policy, no patch] Process for dealing with EOL PHP versions during the Drupal 10 and future release cycles too.

This would mean we'd need something like 'LTS mode' for the overall major branch, rather than designating a specific LTS branch, otherwise it's whether doing more planned, scheduled releases is less workload overall than unplanned unscheduled releases which might or might not have to happen.

maybe we can do something about the naming too - "long term support" for 2.5 years is a misnomer.

if I reach my expected lifespan, I will still have to go through 12 or more "long term" releases, lol. I even guess/hope that number to be much higher for most of you who read this.

maybe something like "medium term support", "intermediate term support, "limited term support" would be more appropriate :-)

post made in jest but not entirely

I've attempted to rework the issue summary and title to reflect the remaining undecided parts of this issue.

Following #77, here's my own opinion. Drupal 7 adds overhead to core security releases, so while it continues to be supported with Drupal 7 security releases tied to (hard blocking) Drupal 10 ones, the extra and divergent major branch increases the work required to release an SA.

This can mean either additional unsustainable workload for core/contrib maintainers and the security team and/or fixes not being released at all. Either kept in a private backlog on security.drupal.org or publicly disclosed by the reporter because we didn't respond. Drupal 7 sites are also going to have to deal with the ckeditor4 EOL within the next six months which is outside the scope of even official Drupal 7 support anyway.

Therefore, if Drupal 7 is supported into 2025 or later I think we should only do option #1 or #2. However I don't like option #1 and we could end up in a situation where there are more sites on unsupported 8+ releases than 7.x by then.

Option #2 is possible in that scenario but it could end up at the cost of prompt security releases, patch/minor release quality, burnout of maintainers etc. due to the additional workload involved. However it would be a good compromise for sites and contrib maintainers otherwise.

If we ignore Drupal 7, then I think it is only a choice between option #2 and option #3.

Option #3 is best for the large minority of sites that want/need to stay on a major release until the very last minute, but it's clear additional work for core, security and contrib maintainers - so for me there are obvious pros and cons between #2 and #3, and I'm not sure what's best there.

I think my overall preference would be to commit to option #2 (support until June 2026) soon, after more open discussions and indications about Drupal 7 support. Then review every six months whether we want to attempt option #3 for Drupal 10 and/or Drupal 11+. That would give sites and contrib maintainers a lot more predictability than they have now while being honest about resource constraints and uncertainties while we figure out the rest.

Here's a possible sketch of how we could make the overlap work. There are two things which make it particularly challenging:

1. The longer we support a branch, the more chance of 'something annoying happening' with a PHP minor version or dependency.
2. The longer core supports two major branches, the longer contrib has to support diverging code bases, and this gets even worse with three.

For #1, we have the idea to continue to release minor versions on the older major branch, at least initially, so we can update to minor versions of dependencies and release PHP compatibility fixes, hopefully avoiding a sudden jump or need to fork/backport if there's a security release.

For #2, the biggest issue contrib currently has is that when we introduce a new API to core (for example PHP attributes if/when that lands in Drupal 10.2), contrib can't easily adopt that new API until all minor versions that don't have it are out of support, but that also when a new major version comes out they have to adopt the new API - this creates a short window for things added in later minor releases approaching a new major.

If we have an 'LTS major' supported for much longer, then there'd be a lot more cases where contrib has to maintain two branches or complex workarounds, but we might be able to mitigate that by backporting API changes to those minor releases too.

Could look something like this:

10.4 and 11.0 Dec 2024 (Symfony 7.2)
10.5 and 11.1 June 2025
10.6 and 11.2 Dec 2025, Symfony 7.4, PHP 8.6 support - end of API backports to 10.x
( 10.7?) and 11.3 June 2026 - start deprecating for removal in 13.x
(10.8?) 11.4 and 12.0 Dec 2026 (Symfony 8.2)
11.5 and 12.1 June 2027

In this example, contrib could use new APIs added in 11.1 as soon as 10.4 and 11.0 are out of support, and in 11.2 as soon as 10.5 and 11.1 are out of support.

And then at the other end of the cycle, we'd start deprecating for removal in Drupal 13 one minor release before Druapl 12.0, so that modules can at least theoretically run on both Drupal 10.6 and Drupal 12.0.

The main disadvantage is that sites on 10.x continue to have to update to minor releases to stay in security support, they wouldn't get to a 'patch/security' point the last few months of Drupal 10, but their chances of being able to smoothly update to a security release and eventually the next major are much higher.

We have mature software that still is highly valued in our major releases. The Drupal community has not yet been solicited to raise funds to support an unlimited or vastly prolonged lifecycle(s) however some have already come up and offered to fund it. For us we're still supporting D7/D8/D9 and D10 simultanously in multiple environments and for multiple reasons. I am in favor of vastly prolonged support/maintenance of major releases like D9 and D7. We're doing cutting edge development in D10 and we'd prefer to continue our projects as they evolve than be forced to follow a fixed schedule for everything at once.

@collins405 has previously offered 10000$ per year for Drupal 7 to be converted to Drupal classic and maintained long term.
https://www.drupal.org/u/collins405 . Soliciting the drupal community could raise hundreds of thousands of dollars quickly towards this effort , perhaps millions.

It is my opinion that the Drupal association should immediately begin soliciting funding for extra resources allocated to extended livecycles and an expanded scope.

@joseph.olstad this issue is about major releases where the EOL date has not yet been decided, it's not going to affect Drupal 9.5 which is constrained by Symfony 4 and CKEditor 4. If you want Drupal 10 to be an improvement over Drupal 9 in this regard, then keeping the issue on topic would help.

@catch, the fact that D10 went from symfony 4 to symfony 6 should hopefully allow for a longer lifecycle of D10 compared to D9.

Basically I'm advocating for the longer the support lasts the better it is. The longest possible and there's people who have already pledged funds to finance the resources to extend or move suggested EOLs indefinately.

We discussed #3238652-80: [policy] Decide how long major Drupal versions should be supported in slack and a suggestion was to boil it down to something like this:

On a best effort basis, for API additions to core, either try to backport them to the previous major release or deprecate for removal two major releases ahead. This would be decided case by case depending on what's appropriate for each issue. Best effort means sometimes we'd do neither things (i.e. what we do now, deprecate in the upcoming minor for removal in the next major) when it's particularly complex and/or unlikely to affect many modules.

I think that is probably a lot simpler than the schedule above even if it will occasionally mean some more discussion on issues, but we already have some of that with backports to patch releases etc.

1. I would be to me the best is we stop supporting Drupal 7 at the end of this year. Move it over to a commercial party. For me it is about moving the "drop" forward, not about supporting ancient stuff.

2. I think that it would also should not support newer PHP versions on Drupal versions that are in LTS status. For instance Drupal 11 will be released in the summer of 2024 and PHP 8.4 is expected to be release in the end of 2024. Therefor Drupal 10 should not support PHP 8.4. Just like when you try to run Drupal 10 with PHP 8.0 you get an error warning. Do the same when you try to run Drupal 10 with PHP 8.4. If you want to use PHP 8.4, great then use Drupal 11. Let's not waste time on adding support for this.

Those resources we save can be used on getting those strategic initiatives and other stuff done faster!

I have created #3363102: [Policy] How to select the minimum required database versions.

The problem with not backporting support newer versions of php to older releases is that you could find yourself in a situation where you cannot support the newer version of drupal on the same system as your existing version.

While IMO php minimum version support should not increase outside major drupal releases, there is value in increasing the latest version supported as new php versions are released.

@NaheemSays that should generally work fine regardless of the finer details here.

i.e.

PHP 8.3 is released the end of 2023. Drupal 10 adds support.
Drupal 11 is released mid-end 2024 - the highest version it can require is PHP 8.3 because PHP 8.4 doesn't exist yet.

Whether we then try to support PHP 8.4 in Drupal 10 comes down firstly as to whether it's straightforward to do so, but also whether we think it will insulate us against PHP dependencies raising their minimum requirements before it goes out of support.

I think we can say we'll aim to have Drupal 10 work well on the minimum PHP version that Drupal 11 requires, and for anything else see how it goes.

#3355675: Drupal 9 uses PHP syntax that's deprecated in PHP 8.2, so exclude that from error_reporting() and DeprecationListenerTrait is an example where we partially added support for PHP 8.2 to Drupal 9.5 after initially giving up - mostly by ignoring deprecation messages so that tests will pass.

@arti_parmar I see you have opened a merge request on an issue that is a discussion and not code related.

The amount of issues you have posted in the last few days leads other contributors to think you may be attempting to gamify the Drupal attribution system.

When you open a merge request or post a file it ticks the credit box for attribution and creates more work for maintainers when they close the issues. Please refrain from opening a merge request unless you are working on code.

I am going to go through some of the issues you are working on and give you individual examples on issue queue etiquette and how you can better improve your contributor experience working within the community.

Here is a list of resources to help you on your contribution journey, thanks!
Issue Queue Etiquette
Contributor tasks
Adding tags to issues and using tags

I have unticked the attribution box, as you did not contribute to the conversation, let me know if you have any questions.
~AmyJune, Core Mentor and CWG Community Health team member

I'm torn.

On one hand, having such a long cycle between required updates is a good selling point.

On the other hand, if clients are all able to put off major updates for 4 years it's not going to be pretty when everyone wants an upgrade all at once and they all need to go up two major versions [end 2c]

Total cost of ownership is reduced by delaying as long as possible expensive changes such as requiring a new version of Symfony.

I'm a proponant of a two streamed approach. On one hand, the cutting edge is fun and exciting in some ways but it is also fun and exciting to see your 2011->2019 project running on the latest D7 core with the latest version of PHP (8.2) but still compatible with 5.3, On the other side of the coin, others just want to keep their existing apps running as long as possible while they innovate on new ideas in other projects.

This is why I have for the past couple years made a lot of noise about what I call a Drupal classic and Symfony Drupal double stream. In my ultimate fantasy D7 becomes what I call Drupal classic with a limitless future retaining compatibility as the prime directive going forward, and D8+ becomes symfony Drupal , so S6 Drupal would be D10, S7 or S8 Drupal would be Drupal 11 cutting edge assuming all the benefits and risk of an ecosystem it has assumed.

I've pretty much given up beating this dead horse now that Dries dropped the no-extension news for D7. With that said Drupal 10 is an 18 month improvement on D9, D10 will be supported until the end of Symfony 6 which is expected to be January 2027. Whereas Symfony 4 had a shorter lifespan with D9. So things appear to be going in the right direction with hopefully Symfony extending it's support lifespan of Symfony major releases so that we can also extend the major Symfony based Drupal releases.

@catch and I discussed this at length today and here is what we came up with. Given:

• We want to support Drupal 10 as long as possible.
• We need to at least provide minor dependency updates so D10 continues to have dependency security coverage throughout that time.
• Contrib not having API compatibility for supported branches creates upgrade barriers, so we want to provide key APIs simultaneously across major versions.
• But (per research by @lauriii) many site owners and even agencies consider site updates more risky than security vulnerabilities, so we want to have branches available that are more stable with fewer updates.
• And release managers know from D8 and on that internal API breaks are disruptive for contrib.

We propose this:

This introduces the concept of a limited support minor, which is something between regular minor support and security support. It includes:

1. Minor-version dependency updates (plus CKEditor breaking versions).
2. PHP compatibility fixes for the latest PHP version.
3. API additions that were committed to D11, where these API additions are important API parity for contrib. These are backported as new APIs only, without any usage conversions. Release manager discretion.
4. No internal BC breaks insofar as it is possible.
5. Backports of safe major and critical bugfixes (those that do not require deprecations, internal BC breaks, or serious behavior changes).
6. Bugfix releases issued at release manager discretion rather than monthly.
7. Six months of additional security-only support after the six months of limited support, same as any other minor.

The release schedule plays out thus:

1. Drupal 11.0 is released alongside a minor version of Drupal 10, as per current practices. This is 10.3 assuming we release in June or August 2024, or 10.4 if 11.0 comes out in December.
2. When 11.1 is released, we issue a limited support minor of Drupal 10. (Most likely 10.4, or possibly 10.5 in the December D11 scenario.)
3. 12.0 comes out in June 2026 along with 11.4 (or 11.3 in the December scenario).
4. 10.5 receives at least 12 months of extra security coverage (rather than six) until December 2026, meaning it overlaps with Drupal 12 support.
5. We may extend 10.5 further into 2027 if that seems feasible and necessary, but we make that determination during Drupal 12 preparation and/or after its release.
6. When 12.1 is released, Drupal 11 then begins receiving the limited support minors.

One extra thing not in #94 is that 10.5 patch releases, or a 10.6 if we added one in, give us the chance to provide PHP 8.48.5 support in Drupal 10 - and PHP 8.48.5 is the highest possible PHP version we would require for 12.0.0 since it would be released six months before. This would allow sites to update Drupal major releases twice without a hosting upgrade in between.

Another thing @longwave reminded me about that I forgot to put in my post is this: It's probable that backporting API compatibility but not everything will lead to extra overhead since we'd have to write a lot of completely different backports and then other things would not cherry-pick cleanly. However, in the above proposal, we give it our best effort for the first limited term minor. We can always scale the next limited minor down toward dependency updates and security if it's too unwieldy and the contribution overhead is outweighing the benefit to contrib of the API additions, or if the codebases are just too divergent.

Hmm yeah. Based on PHP 7 there probably won't actually be a PHP 8.5. It will probably be PHP 9, in which case backporting to 10.5 patch releases (or even D10 at all) would be much harder. We may need to adjust the specifics according to whatever PHP does.

Re #100 Symfony calls their X.4 releases "LTS", I wonder if we should follow suit for our X.4 and onward releases as well.

So 10.3 would be a normal release and then 10.4 would be LTS, where some users will want all the new shiny features and they upgrade to the newer 11.x series. Or for users who are more conservative, they can stay on LTS branches - waiting on 10.4 LTS then 10.5 LTS until 11.4 LTS is released, and only then upgrading.

As I mentioned to @longwave in Slack I did almost put "LTS" in the diagram, but changed my mind for the following reasons:

• We deliberately dropped the LTS terminology already for 9.5 since the minors were not long-term support, in that it was the same 12-month term of support as other minors.
• We're also still issuing semver minors, rather than patches only, so it's not exactly like Symfony's LTSes.

We could use the label for 10.5 in the above diagram though, or refer to a "Drupal 10 long-term support phase" during which we release limited support minors, or minimal minors, or whatever label we come up with that fits #94's policy specifics the best.

Is the idea that we might release 10.6, 10.7, etc. if needed to keep up with minor versions of dependencies, so it's not so much that we'll support 10.5 for 18+ months, but that we'll support "^10.5" for 18+ months?

Or, is the idea that we'll relax our semver strictness if needed and allow minor version dependency updates into Drupal patch releases of 10.5? But if we take that approach, then why not start that with 10.4 (or whichever the first limited support version of 10 is)?

Well, neither really. We're definitely not relaxing semver; the scope of what we're proposing to backport is way too much from an API standpoint to go into patch releases. And definitely no 10.7; at that point we're already dealing with two branches of active Drupal 12 support so it's time to EOL D10 if its last minor is going to be insecure. The timeline we came up with has us supporting four branches at a time, no more, and 10.7 would bump it to 5 which is too much.

I mean what is in the picture. I would plan for 10.5 to get a simple extra six months of security coverage, like 8.9 did, or maybe a little longer if dependencies permit.

We allow ourselves the option to issue a 10.6 if we really need it, but we're already allowed to issue unscheduled minors if needs must under existing policy, so nothing new to add there.

Regarding the PHP compatibility aspect: Most PHP compatibility fixes are backportable; a few are not. If we're dealing with a PHP 9.0 that year, that's going to be breaking changes even by PHP's definition and that's not worth trying to shoehorn into a mostly EOL branch if it also breaks our APIs. Backport what compatibility we can; let be what we can't. If there is a PHP 8.5, we can decide what to do when that schedule is announced and/or when we have a PHP alpha to test against.

Edit: We would issue 10.6 if (for example) we could get compatibility with the latest PHP version for the last year of D10 support, but only with a dependency minor update where the previous dependency version had a fatal error with the PHP version. Or if PHP compatibility was easily achieved but required disruptive but minor-safe changes in Drupal. Things like that.

PHP versions: I meant PHP 8.5.., have edited the comment to clarify. PHP 9 definitely might introduce complications, although if PHP 9 is a new minor release + turning deprecations into errors, maybe compatibility will still be possible in 10.x, but we won't know until it gets to alpha or so.

10.5 vs. 10.6: like xjm says I think we would reserve the option to release 10.6, but at that point we might say it only gets 6 or 9 months support if there are other dependency EOLs making it very hard to extend overall support into 2027. But we would anticipate definitely needing to release 10.5 whatever happens.

If I understand the above correctly, that's actually pretty significant, because it means a site can go from "^10.3" to "^11.4" (from the last non-limited minor of one major to the last non-limited minor of the next major), without needing to do any disruptive minor updates (by "disruptive", I mean where the version you're updating to is not a "limited" minor) in between, which was the original goal of this issue :)

I had to read this twice, but I think I get it and also that the answer is yes.

If you install on 10.3, then you could do -> 10.4 -> 10.5 -> 11.4 with comfortable security overlap between 10.5 and 11.4. And 10.4 and 10.5 will have less disruptive changes in them.

The contrib update side of things is trickier but potentially also OK:

Let's say API parity is going reasonably well, so that 10.5 and 11.2 have enough in common that a significant number of modules are still maintaining a single branch for Drupal 10/11 compatibility. Doesn't need to be all of them, just a lot for the modules that would prefer to do that for a while if they can.

11.2 will then be in security support until 11.4.

So for a contrib module that wants to adopt new APIs added in 11.3, that aren't in 10.5/11.2, in such a way that they need to make a new major branch, 11.4 is the most likely time to have that major branch if they haven't done so already. At this point the 10.x-compatible branch goes into security-only mode and stops getting bugfixes. This is something we can flesh out in #3357742: Guidelines for semantic versioning and Drupal core support.

If you are aiming to update from 10.5 to 11.4, it looks something like this:

1. Update all your modules to the most recent versions that support ^10 || ^11
2. Update core from 10.5 to 11.4
3. At this point you might have some contrib modules with new major branches that only support ^11.2 or ^11.3, and you can update to them to continue getting bug and feature releases. However these will in the main be fairly new major branches that any site that started on 11.0 would also need to plan to update to during the same period.

So the longer 10.x support period allows people to update later, but the 'limited support' concept for 10.4 and 10.5 hopefully means less total drift between the majors, so they can still do a fairly small hop to 11.4 and keep going from there.

If you stay on 10.5 long past 11.4, then you will end up with a much bigger backlog of #3, and a much longer time where your ^10 compatible contrib module branches stop receiving bugfixes, but the LTS-ness of 11.4 should allow us to communicate this to both contrib authors and sites.

We discussed more last night/yesterday/this morning in our respective timezones and made a couple small tweaks:

Changes:

• Extend the diagram to show the consistent pattern from D11 to D12.
• Bikeshed terminology. @longwave and @quietone were concerned that the concept of a limited support minor would be a Drupalism, and compared these to LTSes of Symfony etc. But they're not LTSes because they're still only receiving 12 months of support each. The compromise we landed on was referring to the entire post-major-release support timeframe as the "LTS phase" and (for now) the individual minors as "reduced support minors" (with the same policy definition outlined in #94).

@effulgentsia also regarding:

If I understand the above correctly, that's actually pretty significant, because it means a site can go from "^10.3" to "^11.4" (from the last non-limited minor of one major to the last non-limited minor of the next major), without needing to do any disruptive minor updates (by "disruptive", I mean where the version you're updating to is not a "limited" minor) in between, which was the original goal of this issue :)

Keep in mind that even though 10.4 and 10.5 patch releases are low disruption, and 11.5 etc. patch releases are low disruption, 11.0 is still a major version, and 11.1.0 through 11.4.0 will still contain all the normal disruptions of a fully supported minor release. So your patch releases will be less disruptive, but the technical debt when you try to go from 10.5 to 11.4 is still a lot. Most agency people I've spoken to say jumping two minor updates at once is a lot of technical debt; this would still be the combined technical debt of four minors and a major.

10.5 and 11.4 also won't be perfectly compatible for the site owner from an API standpoint since we are only backporting the most important API additions, not everything. The intention of doing so is to make things easier on contrib. It will help for custom code as well, but it still won't mean full parity between 10.5 and 11.4.

Plus, automated updates is on its way, so the cost of patch release maintenance is going to go down. As a result, staying on the old branches to have fewer patch updates will eventually become less popular. It's still one of the personas I referenced in our discussions, but with AU if you stay on old branches you are simply deferring technical debt to have a lot of updates at once.

This initiative is welcomed and I applaud this initiative.

With that said, please reconsider the hard EOL of January 2025 for Drupal classic.

Drupal classic not being reliant on symfony or tied to Zend PHP EOL dates offers smooth future roadmap because it does not require symfony. This allows clients to build very long term stacks and leverage PHP security releases from vendors such as Red Hat (and others) to provide security backports for current and older versions of PHP and those running Drupal classic are able to do so with minor release PHP security backport updates long into the future.

Hosting options for Drupal classic are vastly larger and less expensive than hosting options on cutting edge PHP.

A stable api not tied to symfony has enabled many large organisations using Drupal classic without symfony to be able to build and deliver deep and rich experiences without spending time worrying about PHP EOL or Synfony EOL.

I urge the D.A to reconsider the roadmap for Drupal and to open it up to Drupal classic along side Symfony based Drupal.

I've seen what an extremely stable API has done for École Polytechnique de Montréal, they have built 180 sites , all integrated with various internal and external systems, single sign-on, event calendar, advanced functionality specific to their needs. Migrating to symfony Drupal would increase their maintenance costs immensely, redirect their focus to symfony instead of end users and custom deliverables. There are compelling reasons why the D.A should solicit financial support from the community for a continued Drupal classic initiative to keep the excellence going forward.

I understand that there are also compelling reasons to move forward with Symfony Drupal and I appreciate all the hard work being done. I enjoy working with Drupal 10 also however it's very challenging to keep up with it. I would really like to see us co-exist and agree to move forward indefinitely rather than force obsolescence on a large portion of our base.

@joseph.olstad - this issue is about Drupal 10 and upwards, it doesn't even cover Drupal 9, if you want to relitigate the Drupal 7 EOL please do it elsewhere instead of repeating off-topic comments here.

@catch, I think what would help with Symfony and anyone depending on Symfony is if Zend could be convinced to switch from a 2 year cycle to a 3 year cycle. This would mean that a release such as PHP 8.3 would be supported by zend for 4 years instead of 3.

It would give us a bit more time in our lifecycles.

I've got some projects that are easy to upgrade and others that take significantly more time and more effort.

Would it be possible for Zend to be convinced to stretch things out by 12 months and allow the rest of us to also stretch out by 12 months?

ALTERNATIVELY:
Maybe without changes to "Zend", Symfony (or some third party vendor supporting Symfony) could be convinced to do for Symfony what third party vendors like Red Hat and Canonical/Ubuntu do for security backports of PHP.

One way or another it would be nice if we had another 12 months of support for Symfony releases.

In enterprise solutions it's not uncommon to be looking for 15 or 25 years of support. There's still COBOL apps being supported that were originally written 40 years ago. Large enterprise solutions tend to naturally adhere to much longer lifecycles than enthusiasts do.

In this case the extra 12 months would still be cutting edge for Enterprise.

We discussed this with @xjm @Dries, @Gábor Hojtsy, @longwave, @alexpott, @justafish, @nod_, @lauriii, @ckrina at DrupalCon Lille and there was strong consensus in the meeting that we should try this.

I realised as I was about to post this comment that the issue summary was out of date with #105, so I have updated it significantly to try to match the diagram and comments on this issue that led to it. The wording might need some help, but marking RTBC for the overall policy change. We would like to do a blog post announcing the Drupal 11 release windows for next year (already decided but not actively promoted yet), along with the Drupal 10 support cycle as discussed in this issue.

The exact Drupal 10 EOL date is still TBD, and so is the exact nature of the issues that we'll backport, but as long as we can account for that in the blog post I think that is fine, and we can try to be more explicit as everything gets closer.

I'm untagging this for the various sign-offs, and per #3389468: Document how the core committers reach agreement on core policy issues marking RTBC for 14 days of final feedback from core committers.

(Though we're actually going to try to get this one done in fewer days than that so we can announce it alongside D11 opening and D9 being EOL.)

With my very bad graphics skills, I attempted to make an svg of the timeline. Changes from @xjm's version are that it assumes the June release window, and I tried to minimize the vertical space by keeping each major release on a single line.

Not tied to the visual presentation at all, but if we can embed an svg directly as text, we'd be able to update the version numbers as we go rather than having to recreate images.

</p>

Since the 'real' dates are on Drupal core release cycle and the graphic is on an overview page about the cycle itself, the dates are only examples anyway. Although, it would be nice to be able to keep it updated easily.

I had the same thought a few hours ago, about having an easily updateable template for the Core release cycles diagram on the Overview of the release process page and created #3399348: Commit a mermaid version of the core release cycle diagram to core. I created it with Libreoffice Impress, but it looks like it can export in SVG-format, for easy future updates.

An SVG is a great ide!. I was trying to achieve something similar on a new documentation page earlier this year. I was trying to do it with HTML/CSS but was stymied by not being able to apply CSS styles (understandably). #3357187: Suggestion for "Drupal core release cycle: major, minor, and patch releases"

Yes, SVGs are cool! I remade it in SVG-format in Inkscape. Aligning everything to a 1200px grid made everything so much easier. The diagram can now be updated via a text editor, though a PNG still needs to be generated, since SVG's are blocked on drupal.org due to security concerns, see #1730120: Allow svg, eps, ai and indd file uploads via static file domain and #2868079: Sanitize OR add Content-Security-Policy for SVGs.

I'll comment some more in the other issue.

We can't embed SVGs on d.o yet, unfortunately.

The current diagrams exist in the committer drive and are fairly easily updated. I can share them for global view, if that's helpful. (We create new ones by making copies so that the previous one is still available.)

I don't get the diagram in #112; it seems wrong to me. I also like having a universally usable, peer-editable format that doesn't require special software to create. (Though, I was unaware LibreOffice could create SVGs; that is helpful. SVGs would also require fewer fiddly position adjustments.)

I added global view permission to the release timeline folder in the committer drive:
https://drive.google.com/drive/u/0/folders/10bXEtdzIO6sbKzRtFjNv8J108ym2...

You can see there the graphics we've created going back to 8.1.x.

The particular diagram for this issue is:
https://docs.google.com/drawings/d/1SHyfbx6Fq1LAMrd9Q6bCtlzZd8kkzXt07hLm...

I did start with Libreoffice Impress, but switched to Inkscape (open source Illustrator alternative) for the SVG creation. Since it is an SVG, version updates can be done directly in the file via text editor, and a PNG created from that. This is the latest iteration, in #3399348: Commit a mermaid version of the core release cycle diagram to core:

What would actually be great would be a script to generate an SVG given an input array of versions and dates. Not worth it though until we can embed SVGs without having to export them to PNG.

Note also that the transparent background is not accessible with a PNG because in dark mode or custom stylesheets the text is illegible (black text on black background). If a text color is hardcoded, so must the background be.

Here's an updated high-res diagram showing D11 and D12 both in June, since that is the ideal scenario (and since the August release window results in an identical schedule for everything except 11.0/12.0 themselves). I condensed the height and width a bit so that the font will be larger when embedded in the handbook page.

Improving the contrast a little for LTS phases, since it is washed out on my Apple display.

@effulgentsia There is actually already a JS chart generator for core releases that someone made (...in a GitHub repo somewhere; can't find it since the handbook migration). It's just that we can't embed it on d.o even with Full HTML.

@catch pointed out that there's a typo in my diagram; fixed here.

One question. So module naintainers may be expected to support `^10.3 || ^11 || ^12`? Because each will have some sort of security support yet a wide range of deprecations?

Or will there be fewer deprecations in 11?

Saving some issue credits. (@ressa's work will be useful in the future hopefully, but is actually out of scope here.)

Also adding credits for in-person committer discussion contributors at DrupalCon Lille, and @volkswagenchick for mentoring.

@mglaman Regarding:

One question. So module naintainers may be expected to support `^10.3 || ^11 || ^12`? Because each will have some sort of security support yet a wide range of deprecations?

Or will there be fewer deprecations in 11?

See this item from the summary:

Backports of new API features, which we think will enable contributed modules to continue to support both versions easier. We would not backport everything, only issues which we think will make things genuinely easier for contrib modules without introducing instability to Drupal 10, and issues will be marked 'to be ported' after an 11.x commit - i.e. we won't require a backport MR up front.

So, the hope is that the same module branch could be used for the whole length of D10 and D11, or D11 and D12, with less overhead than there is currently for contrib maintainers. Core only supports two major versions at a time, not three, and there is only a seven-month timeframe or so where forward compatibility for an unreleased major would be needed. It's up to the maintainer whether they support all three branches during that short timeframe, and whether they do it in a single branch or two minor/major branches.

Also yes, I expect there will be fewer deprecations in D11 and subsequent versions due to the fixed two-year cadence. Certainly we'll not have a repeat of D8's deprecation backlog, hopefully no repeat of D9's CKE5 soon or ever, and D10 already contains fewer deprecations than D9 did seven months before the target window.

Thanks, @xjm. Core may only support two major versions. But technically someone could upgrade form 10.3 to 12, hence a contrib needing to support three branches. This has been a major pain point in major version readiness, spreading support across real-world sites that are upgrading. Shorter minor release cycles actually makes this easier, so there might be less pain.

I just wanted to raise it, just in case. Once this is official, it'd be great to have documentation on best practice for Drupal core support in contributed projects (see also @catch comment in #104.)

@mglaman Can you maybe file a followup core docs issue for that?

Thanks for the tip about Apexcharts @effulgentsia, it has a lot of cool features. I created a proof of concept in #3399348-20: Commit a mermaid version of the core release cycle diagram to core.

For #138.

But technically someone could upgrade form 10.3 to 12, hence a contrib needing to support three branches.

#2942096: [policy, no patch] Remove old update hooks prior to each major version (Drupal 10 and later) makes that impossible unless we also change things there. Every major release since Drupal 9, we've enforced that you have to be on the penultimate minor release to be able to update at all. So if we release in June both times, that would be 10.2 to 11.0, and 11.3 to 12.0. If we don't do that, people end up running updates written five years ago alongside updates written last week, alongside untold numbers of contrib updates, and no amount of test coverage can cover all the things that can go wrong.

Someone could do a two-stage update where they update to Drupal 11.3 first, then Drupal 12 immediately afterwards, then switch their production site over, but if you're doing that you'd have to be using three branches of your own code base anyway - so a module that supports 10/11 and 11/12 is still doing enough.

I think that's a valid approach for a complex site that's out of date, but it's not the same as going direct from 10.3 to 12.0 running all intermediate updates in one shot.

@xjm not the greatest but I at least got something open before I forgot or life got busy #3400849: Document best practices for Drupal core support and semver for contributed project maintainers 😅

Thanks @mglaman!

https://www.drupal.org/blog/drupal-10-will-be-supported-until-the-releas... was posted on November 22. The Drupal core release schedule page still needs updating though, it currently lists 10.4 as being conditional on 11's beta requirements, only mentioning it if the 11 beta is late. https://www.drupal.org/about/core/policies/core-release-cycles/schedule

https://www.drupal.org/about/core/policies/core-release-cycles/release-p... has the right information about the ~4 year release cycle.

https://www.drupal.org/about/core/policies/core-release-cycles/schedule is not wrong as such, all the non-December release windows don't mention 10.4, but they all finish long before then, so don't preclude 10.4 either. I think the answer would probably be to add an '11.1 + 10.4 December' line to both the June and September sections?

Made this change: https://www.drupal.org/node/2383987/revisions/view/13347780/13350615

Updated the IS by

• Fixing the link for image
• Linking to the updated documentation
• Update remaining tasks

It looks like the "allowed changes" page still needs an updated.

I've added a section for maintenance minors to the 'Allowed Changes' and move the details from the 'Release process overview' there. Those details are replaced with a generalized statement about the changes which I think is suitable for an overview.

I think that completes everything here.

I think the changes in #149 are good. We are still going to find bits of documentation to improve around this but we can do that without this issue being open. Feels really good to mark this one fixed!