Problem/Motivation

Drupal 9 allows us to remove deprecated code and backwards compatibility layers.

However, we also want Drupal 8 modules to be able to run on both Drupal 8 and Drupal 9 per #2822727: [policy, no patch] Adopt a continuous API upgrade path for major version changes and make the transition between releases as smooth as possible.

This means that if (version numbers are examples only) 8.10.0 and 9.0.0 are released on the same day, that would be no window for Drupal 8 modules to update for new deprecations introduced in 8.10.0 that are removed in 9.0.0.

Proposed resolution

If 8.10.0 and 9.0.0 are released on the same day, only remove deprecations and backwards compatibility layers added in Drupal 8.8.0 or earlier.

We may have to make exceptions for Symfony or Twig backwards compatibility breaks, since we can't update for those major versions until we actually release Drupal 9, although we could also aim to document these in advance too if possible.

Advantages: any module that is up-to-date with 8.8.0 by the time 8.10.0 is released a year later will have a good chance of working on 9.0.0 too.

Disadvantages: one year's worth of deprecated code that could have been released in 9.0.0 will need to be supported until 9.x's end of life.

Remaining tasks

Document this as a policy if it's agreed. Once we are a year in front of the Drupal 9.0.0 release, start marking deprecations for removal in 10.0.0

User interface changes

API changes

Data model changes

Comments

catch created an issue. See original summary.

catch’s picture

Version: 9.x-dev » 8.6.x-dev

Hmm we need to do this in an 8.x release, so moving back.

xjm’s picture

Priority: Normal » Major

Major I think.

plach’s picture

Disadvantages: one year's worth of deprecated code that could have been released in 9.0.0 will need to be supported until 9.x's end of life.

Maybe we could remove code deprecated in 8.9.0 and 8.10.0 in 9.2.0? This would give contrib authors one full year to make sure their modules are 9.x compliant. I guess this would be feasible if we adjusted our BC policy to reflect that. And given that we aim to make the 8.9.0 -> 9.0.0 transition as smooth as the 8.9.0 -> 8.10.0 one, I guess it would be reasonable to expect that a 9.1.0 -> 9.2.0 transition, where only one year's worth of deprecated code is removed, would be at least equally smooth.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

Status: Active » Closed (duplicate)