Problem/Motivation
Following alpha releases of Drupal 9 (see #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1), we have some criteria for when beta releases would be tagged. Postponed on #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1.
Proposed resolution / Must-haves prior to tagging Drupal 9.0.0-beta1
8.9.x and 9.0.x will enter beta at the same time and will have the same beta stability requirements as a normal minor release. Additionally:
- There must be no outstanding issues to update PHP and JavaScript dependencies (i.e. they should be on the latest release of the latest branch we intend to ship with). Also unused dependencies should be removed prior to beta. See #3009213: [META] Update / reconsider dependencies for Drupal 9.
- All deprecated code usages and backwards compatibility layers must be removed and deprecations properly documented - we can't remove deprecated code that is called by Drupal core. (see the @deprecated tag). This includes deprecated JavaScript libraries etc.
See:- #2716163: [META] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules on the Drupal 9 branch
- #3007329: [META] Drupal 8 core must not use any deprecated code, must be enforced by automated testing
- Any critical Drupal 8 upgrade path bugsmust be resolved in 8.x so that sites are not stranded on pre-8.9.x versions due to known core bugs.
- Also in 9.0.x, updates from versions prior to Drupal 8.8.x must be removed and hook_update_last_removed() implementations added, pending final decision on #2942096: Decide when to remove updates and tests for older Drupal 8 minor releases. The combination of both of these is designed to minimise the surface area for 8-9 upgrade path bugs. We must also have test coverage for updates added after 8.8.0 which does not depend on pre-8.8 database dumps #3089900: Drupal 8.8/8.9/9.0 update test coverage.
- Any known 9.0.x-only security or data integrity criticals must be resolved.
Should-haves
These issues are not hard blockers to releasing Drupal 9, but there would be significant negative consequences of them not being completed in time for Drupal 9's release. Outstanding should-haves may cause 9.0.0 to be deferred from the June release window to the August window.
- We should complete #3075954: Remove duplicate scaffold files for future compatibility with Composer handling changes and Drupal.org.
- Any critical API changes, API additions, or data model changes should be completed, as these changes will no longer be allowed during the beta.
All Drupal 6 and Drupal 7 -> Drupal 8/9 core content migrations should be stable. In practice this mostly means multilingual migrations #2208401: [META] Stabilise Migrate Drupal Multilingual module . If we don't do this, we can't expect people to migrate from Drupal 6 and Drupal 7.
- We should have adopted a policy for PHP 7.x version support, as this needs to be announced as far as possible before the LTS and 9.0.0 release so hosts have time to upgrade. #2917655: [policy] Decide on PHP 7.x support status
- We should provide accurate update recommendations (9.0, not a non-existent minor version of Drupal 8) on the Status Report (
/admin/reports/status). #2991207: Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases.
- We should have a proper policy for CSS and markup changes, see #2659890: [Plan] Drupal 9 markup and CSS backwards compatibility.
Drupal.org should be able to fully handle contributed projects that are compatible with both 8.x and 9.x and not assume core compatibility based on version/branch name:
#3054433: Support multiple core branch functionality for contributed projectsThis spans multiple projects and areas such as project listing, composer façade, update.xml from drupal.org and localization files.
There may be minor configuration translation migrations or contrib -> core migrations still outstanding which would be great to clean up but should not actually block release.