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.
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.
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.
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 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 email@example.com 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 backdropcms.org 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.
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.
Archiving your project
In the rare case that your project needs to be archived, please update the README.md 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.