Managing branches & releases

Drupal core usually supports two major releases, as explained in the release process overview. Therefor, 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.

When to make new release

The decision is based on how the contributed project code the relationship to Drupal core code. The changes that will prompt a new release are listed below 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 (such as 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

Remove support for branch

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

• Add a note to the project page clearly saying which branch & releases are no longer supported by the current maintainer(s), and that new co-maintainer(s) are being sought to help manage them.
• Switch the project's Maintenance status to Seeking co-maintainer(s).
• Ignore issues for the deprecated branch and unsupported releases.
• Do not mass close issues on the unsupported versions as it makes it harder for anyone who wants to take over maintaining the old versions.
• 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 for anything that is safe and marked RTBC.