Managing branches and releases

Drupal core usually supports two major releases, as explained in the release process overview. Therefore, contributed projects should also support more than one major core version. 

It can be a bit of a struggle to maintain themes, modules and distributions for multiple major releases of Drupal core. This page explains how to decide when to make a new release and how to mark a branch as unsupported.

Creating a new release

The changes that will prompt a new release are listed next for each type of release.

Major version

• Dropping compatibility for a currently supported version of Drupal core
• Introducing breaking changes from Symfony or another dependency where backward compatibility (such as adding types to method signatures) cannot be supported
• Introducing impossible dependency resolution, for example the module requiring Guzzle 7 when a previous Drupal core version required Guzzle 6

Minor version

• Dropping compatibility with an unsupported version of Drupal core

Patch version

• Adding compatibility with a new Drupal core major version while maintaining backward compatibility for all previously supported versions

Removing support for a branch

If you don’t want to maintain a branch, do the following:

• Add a note to the project page clearly saying which branch and releases are no longer supported by the current maintainer(s)
• Ignore issues for the deprecated branches and unsupported releases
• Releases should ideally be moved from supported to unsupported on Wednesdays to give site admins time to react during the work week; changing the status of a release to "unsupported" may have security implications, so it is best to change support status in coordination with security release timing
• For bonus points, wrap up a new release after committing changes done in issues marked Reviewed & tested by the community