Continuous upgrades between major versions

Beginning with Drupal 9, major core releases will aim for a continuous upgrade path from the previous major release.

Guidelines

The next major release will have the same public API as the last minor release of the previous major release.

When a new API is added, the old API is deprecated. The old API will not be removed in the current major release. The old API is removed in a future major release.

All APIs will be deprecated in a consistent manner.

All changes should be backwards-compatible with a designated minor release of the previous major version. The designated version is usually the minor release scheduled for the June release window of the major release.

Not all code can be deprecated in the designated minor and later minor releases. In this case, the deprecation moves to the first minor release of the next major version.

Extension removals are allowed in the designated minor release.

Tests of deprecated code are required when there is a backwards compatibility layer with its own logic.

The next major release will also

• increase PHP and system requirements
• include dependency upgrades to new major releases
• remove deprecated code schedule for removal

Procedures

The release managers should announce details on a release meta issue and possibly a core blog post.

Developers are advised to consult the The Drupal deprecation policy for how to deprecate code.

Project maintainers are encouraged to keep up with core deprecations. This will reduce the work needed to make projects compatible with the next major release.

Project maintainers are encouraged to maintain compatibility with all supported major Drupal core versions. When adding support for a new major core version, the default should be to add compatibility in the current stable branches without dropping support for the previous version. Similarly, support for out of support Drupal core versions can be dropped in minor releases of contributed modules without requiring a new major version.

Where modules rely on new APIs not available in the previous major core version and without an easy way to provide compatibility, a new major version can be created.