Creating Releases
Releases for projects—modules, themes, or layouts—in the Backdrop contrib repository are automatically published on BackdropCMS.org in the appropriate section (Modules, Layouts, 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. You will see right away if there was an error during the packaging process, as a notice will appear on the release page.
Notes on semantic versioning on Backdrop contrib projects:
- 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.x.
- For new modules written 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, within reason (see below).
- For pre-release projects, you may wish to append “-alpha1”, “-beta2”, etc. This is acceptable and won’t cause problems with the packaging script.
- For your sanity, and the sanity of people using the project, use small sequential numbers for each release. Something like 1.x-1.20230726.001 wouldn't be sensible, since there are not 20230726 feature releases for that project.
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 BackdropCMS.org 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.
There are two situations where administrative intervention may be needed:
- Changing the recommended branch.
- 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 BackdropCMS.org.
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 security@backdropcms.org to begin this process. Please see Security Releases for more details.
Who can commit to your project?
In addition to maintainers, there are two other groups of people who are authorized to commit to all projects. These commits will happen under limited circumstances, and usually only in the absence of a maintainer response.
The Backdrop Security Team can make limited commits to all projects.
The Backdrop Security 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, and if an issue is deemed sufficiently critical, the security team is authorized to commit directly to any project. The Security Team is authorized to issue new security releases.
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 can make limited commits to all projects.
The Backdrop Bug Squad 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. The Bug Squad is never authorized to create new releases.
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 backdropcms.org.
Archiving a project
In the rare case that a project needs to be archived, please update the README.md file to explain why it is no longer useful.
A good example of this is the AYAH project, which was archived because the AYAH service was discontinued.