Problem/Motivation
- Drupal provides a consistent 6-month cycle for minor releases, but does not yet provide a consistent cycle for major releases. A consistent cycle for major releases would help Drupal contributors, site owners, service providers, and others, with planning.
- Drupal currently requires site owners to perform a minor core update at least once per year (minors are released every 6 months, but the prior one continues to receive security support for an additional 6 months). The exception to this is that the final minor within a major (e.g., 8.9 and 9.4) is potentially supported for longer (e.g., 8.9 is supported for 17 months from its initial release), but not yet long enough to get onto the final minor of the next major version. Another way of saying this is that if we define this longer-supported final minor as an LTS (long-term support), this means that at least some of the time, there is no supported LTS version. For example, in December 2023, Drupal 7, 8, and 9 will all be EOL, but Drupal 10.LAST will not have been released yet, so at that time all sites will have to be on a non-LTS Drupal 10 minor.
- 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.
- Currently, managing the minimum PHP version is challenging. On the one hand, we want to make new major Drupal versions easy for site owners to adopt, which means setting the minimum PHP version to the 2nd to latest PHP version rather than the latest one (e.g., Drupal 9 was released with a PHP 7.3 requirement rather than a PHP 7.4 requirement). On the other hand, once a site is on a new Drupal major version, the site owner might not have control over their server platform, so we tend to not raise the PHP requirement within the lifetime of that major Drupal version. However, the initial minimum PHP version goes EOL after less than 2 years, and we're left with having to support Drupal on it for several more years after that, which comes with a multitude of challenges.
The proposed resolution of this issue aims to address all of the above. Note that it takes advantage of the assumption that Drupal 10 will be able to get onto the latest version of Symfony (6), which is a luxury that Drupal 8 and 9 did not have.
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).
PHP policy option 1
- Continue the current pattern of requiring the 2nd-to-latest PHP version for the initial release of each new major Drupal version. E.g., require PHP 8.0 (not 8.1) for Drupal 10.0.
- 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.
- 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). The reasoning for this is that with the LTS-to-LTS overlap provided by the rest of this proposal (starting with 10.4 to 11.4), Drupal's users who require the least disruption from upgrades can and should choose to stay on the LTS track, so a small disruption from X.2 to X.3 is immaterial to those users. The corollary is that users who choose the non-LTS track are willing to accept a small disruption from X.2 to X.3. Meanwhile, the benefit of this is it allows the LTS (X.4) release to be up to date on its dependencies, allowing us to provide the longer duration of its support that is the heart of this proposal.
PHP policy option 2
Require the latest PHP version (for example PHP 8.1 for Drupal 10), and continue to support that until the major version End of Life. This ensures we can always use the latest versions of PHP dependencies, while allowing early adopters of Drupal major versions to then continue on the same infrastructure until they need to update. It may result in slightly slower adoption of the first or second minor release of a major version, but this is somewhat offset by the 'LTS-to-LTS' site maintenance approach we'll be encouraging for existing sites.
Benefits of this proposal
- Drupal site owners who want to update less frequently than once per year can do so. The LTS-to-LTS track allows for once-per-2-year updates, with no minor updates required in between.
- Drupal site owners can also choose to upgrade from an LTS to the X+2 major (e.g., from 10.4 to 12.0, and then again from 12.4 to 14.0). In other words, they can skip every other major version, or in other words, only upgrade major versions once every 4 years. However, they then need to do minor updates in between (as has already been the case throughout Drupal 8 and 9).
- TODO: other benefits too
Drawbacks of this proposal
- TODO
Remaining tasks
Discuss.