Documentation Level: 
Documentation Status: 

Creating Releases

Releases for projects—modules, themes, or layouts—in the Backdrop contrib repository are automatically published on in the appropriate section (ModulesLayouts, or Themes, respectively), almost immediately after you create a release on GitHub.

You must tag releases in the format of "1.x-a.b.c" for the Backdrop packaging script to work.

In this format:

  • For Drupal 7 ported modules, “a.b” typically follows the corresponding numbering of the Drupal version. For example, if the Drupal module was 7.x-3.5, your module would be 1.x-3.5 (or perhaps 1.x-3.5.0, 1.x-3.5.2, etc.).
  • For modules written anew for Backdrop CMS, you can choose your own major and minor versions, but typically new modules would start with 1.0.0. An exception might be if a module included or depended on another module or external library, in which case you may wish to follow that source's major.minor versioning.
  • For prerelease projects, you may wish to append “-alpha1”, “-beta2”, etc. This is acceptable and won’t cause problems with the packaging script.

See more about semantic versioning in Backdrop CMS.

Each project has a recommended branch, which is usually the highest major version number (“a” in the example above). The project page on will show Recommended releases, which is the highest-minor-numbered release within the recommended branch. It will also show Other releases, which are the highest-minor-numbered releases in any other branches.

You will see right away if there was an error during the packaging process, as a notice will appear on the release page.

There are two situations where administrative intervention may be needed:

  • Changing the recommended branch. At present, this is not automatically updated.
  • Deleting an orphaned release. If you delete a release from the repository (for example, a release whose name was accidentally mistyped), the release must also be deleted from

In either case, please contact an administrator to make the change. You can post a message on the Zulip chat with your request.

Creating Security Releases

You will need to work with the Backdrop Security Team in order to make a security release for your project. Please contact to begin this process.

You and the security team will choose a Wednesday to coordinate the release, and on that day, when you publish the release on GitHub, someone from the Backdrop Security Team will need to update the project release node on to indicate that this particular release is a security release.

The Backdrop Security Team

The Backdrop Security Team is authorized to make limited commits to all projects. 
The team consists only of trusted members of the backdrop-contrib group who have security experience.

This team will work together with Backdrop maintainers to resolve potential security issues. In the event that a maintainer can't be reached, or if an issue is deemed sufficiently critical, the security team is authorized to commit directly to any project, and issue a new security release.

You may apply to become a member of the Backdrop Security Team by createing an issue in the contrib queue. GitHub members can view a list of people on the Backdrop Security team.

The Backdrop Bug Squad

The Backdrop Bug Squad is authorized to make limited commits to all projects. The team consists only of trusted members of the backdrop-contrib group.

This team is intended to help contributors stay on top of minor bug fixes and User Interface improvements by merging issues that have been "Reviewed and tested by the community" for a period of at least two weeks. 

You may apply to become a member of the Backdrop Bug Squad by creating an issue in the contrib queue. A list of Bug Squad members is visible on

Archiving your project

In the rare case that your project needs to be archived, please update the file to explain why it is no longer useful.

A great example of this is the AYAH project, which was archived because the AYAH service was discontinued.