Problem/Motivation
We need to figure out what has to be done before 9.x is opened.
#2822727: [policy, no patch] Adopt a continuous API upgrade path for major version changes defines what can happen in 9.x, so does https://dri.es/making-drupal-upgrades-easy-forever.
However the nuts and bolts of what this means and when are still undefined. We should keep a list of them here, but make child issues for each.
Proposed resolution
Decide on a set of things that mustshould or could be completed in 8.x before 9.x is opened at all. This is a proposal that should be discussed - there are probably some missing, some that are optional that shouldn't be and vice versa but this at least gives us something to talk about:
Prerequisites to branching
1. The core migration path from 6.x and 7.x to 8.x must be stable before 9.x is opened. We must decide whether to support direct migrations from 6.x to 9.x (catch thinks we should).
2. Either core migrations from 8.x to 8.x or the ability to upgrade 9.x in the same way as an 8.x minor release (using update.php) must must be stable and documented. Both could be available. If there are two parallel systems in place (for example and old and new path aliasing system, then a migration from one to the other must be available. #2607524: [meta] Migrations from Drupal 8 to Drupal 8 and Drupal 8 to Drupal 9
3. Core compatibility must be enhanced so that the same release of a module can work with both 8.x and 9.x. #2807145: [PP-1] Allow projects to work with multiple major versions
4. 8.x core must not use any deprecated classes, functions or methods, this must be enforced by automated testing. #3007329: [META] Drupal 8 core must not use any deprecated code, must be enforced by automated testing
5. Contrib modules must have access to the same testing tools for deprecations as core.
#3002148: Support deprecation testing for contributed modules on Drupal.org
6. We should provide accurate update recommendations (9.0, not a non-existent minor version of Drupal 8) on the Status Report (/admin/reports/status). #2998287: Recommend updating to the next major version when appropriate.
1-6 seem very straightforward requirements, and work towards this is ongoing. We need to be very confident about all these before we announce opening the branch.
Things we can only commit once the branch is open, but would ideally have patches ready for before it does
7. An issue with a core patchshould exist that removes all deprecated classes, functions and methods that can be automated and passes tests.
8. Issues for deprecation and bc-layer removals that can't be automated should have individual issues opened.
9. A patch should be ready that updates Drupal to use Symfony 4 or 5.
10. A patch should be ready that updates Drupal to use Twig 2.
11. [repeat for other PHP and js dependencies]
9. Experimental modules in 8.x should either move to stable before 9.0.0 is released, or be removed, or somehow their situation clarified. Experimental modules should only be added to 9.x, not to the 8.x LTS release. #3007166: [META] Policies and plans for stabilising and/or removing experimental modules in preparation for Drupal 9
In practice this means that the 8.LAST.x branch should not have any beta-stability code in it. It could have release candidate code if we're confident that can go to stable by release. Since we'll probably open 9.0.x at the same time as 8.LAST.x, this means anything not ready gets removed from 8.x and added straight back to 9.0.x I think.