Problem/Motivation
Currently, when we release a new major Drupal version, we also release the final minor version for the prior major version at the same time. For example, we released 9.0 and 8.9 at the same time, and plan to release 10.0 and 9.4 at the same time. This final minor version is supported for longer than other minor versions are (8.9 was supported for 17 months vs. other 8.x versions were only supported for 12 months), so here I refer to them as the LTS (long term support) versions/releases.
Currently, the LTS versions go EOL before the next LTS version is released. For example, Drupal 8.9 went EOL in Nov. 2021 but Drupal 9.4 won't be released until June 2022. This forces site owners to have to update at least twice per major version (e.g., from 8.9 to 9.2, and then again from 9.2 to 9.4).
The goal of this policy proposal is to create an LTS to LTS overlap period, so that starting with 10.LAST, site owners would be able to choose to only upgrade once per major version (from 10.LAST to 11.LAST to 12.LAST, etc.). Although minor version updates are meant to be easy, for many site owners they're still an inconvenience, and an LTS to LTS overlap would remove that burden.
This proposal does not aim to create a 9.LAST to 10.LAST overlap, because due to Symfony 4's EOL, Drupal 9 is constrained to EOL in Nov. 2023, which is before we want to release Drupal 10's last minor version.
For us to create a release cycle that includes an LTS to LTS overlap, we have to consider the following:
- We need to be able to support each major Drupal version (from X.0's release to X.LAST's EOL) for at least twice as long as our major release cadence (from X.0's release to (X+1).0's release). Each Symfony major version is supported for 6 years, which therefore constrains our major release cadence to no more than 3 years. However, 3 years is impractical, because we need some time between Symfony's new major release and Drupal's new major release, and because we want to give site owners a reasonable amount of overlap rather than EOLing X.LAST on the same day as we release (X+1).LAST. Therefore, a 2 year major release cadence is required, which aligns nicely with Symfony's 2 year major release cadence.
- The above means supporting a Drupal major version for 4 years plus our desired overlap length. However, PHP versions are only supported for 3 years, and if we continue to make our major Drupal releases in early June, while PHP releases are in late November, then 6 months of that is already used up. So even requiring the latest PHP version for a new Drupal major version would mean supporting that PHP version for almost 2 years past its EOL. And if we allow the 2nd to latest PHP version for a new Drupal major version, then we'd have to support it for almost 3 years past its EOL. This is in contrast to Drupal 9 where we allowed the 2nd to latest PHP version (7.3) when Drupal 9.0 was released, but due to Drupal 9's shorter lifetime we'll only have to support PHP 7.3 for 2 years past its EOL. In other words, relative to Drupal 9, this proposal extends the lifetime of Drupal major versions by approximately one more year, which means we need to either be okay with supporting PHP versions an additional year past their EOL, or we need to start out with a higher minimum.
- We also have to consider all our other dependencies besides Symfony. Most of our other dependencies don't have a regular major release cadence; rather they release a new major version when something prompts them to. And when they do, some of these dependencies EOL the prior major version right away or after only a year or two. This means that this proposal to extend the lifetime of Drupal major versions by a year or so (relative to Drupal 9) increases the likelihood and duration that Drupal's security team will need to provide security backports for EOL dependencies.
Proposed resolution
- Target June of every even-numbered year as Drupal's major release date. E.g., Drupal 10.0 in June 2022, 11.0 in June 2024, 12.0 in June 2026, etc.
- Release each Drupal major version on Symfony's latest major version (e.g., Drupal 10 on Symfony 6, Drupal 11 on Symfony 7, Drupal 12 on Symfony 8, etc.). This is necessary in order to provide the desired length of Drupal LTS support described below.
- Beginning with Drupal 10.4, target the final minor (the LTS) of each major to be released 3 months prior to the release of the new upcoming major. E.g., release Drupal 10.4 3 months prior to releasing Drupal 11.0. This is in contrast to how we released Drupal 8.9 on the same day as 9.0 and are planning to release Drupal 9.4 on the same day as Drupal 10.0. See #9 for more detail on the idea to stagger them.
- Beginning with Drupal 10.4, support the LTS release until the following LTS release comes out + 6 months. E.g., support 10.4 until 11.4 is released + 6 months (which if 11.4 is released in March 2026, then support 10.4 until September 2026).
- Beginning with Drupal 11.0, require the latest PHP version and continue to support that until the Drupal major version End of Life, which based on the schedule above will be almost 2 years past that PHP version's EOL. Although many site owners might not be on infrastructure that supports the latest PHP version when a new major Drupal version is released, those people can remain on the Drupal LTS version until their infrastructure is ready for them to upgrade.
- For Drupal 10.0, decide on the PHP minimum in #3173787: [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). This policy issue is mostly independent from that one. The considerations are different for that than for Drupal 11.0, because of Drupal 9's earlier EOL.
- Despite the additional support length proposed here, continue our current policies with respect to maintaining backwards compatibility regarding Drupal's dependencies. In other words, accept the increased likelihood and duration of needing to provide security backports for (non-Symfony) EOL dependencies.
- Even if we provide security backports for Drupal's EOL dependencies, it takes time to create and release them, and during that time, sites are potentially vulnerable. Since this proposal is intended to make staying on Drupal LTS releases a viable option, even for risk-averse site owners, provide the option for sites on Drupal LTS releases to upgrade to non-EOL dependencies. See #23.1 for details.
Remaining tasks
Discuss.