If you've created a module or theme for Backdrop CMS we encourage you to collaborate with others in improving and maintaining it. All new modules for Backdrop CMS should be hosted on GitHub.
Join the Backdrop Contrib group on GitHub by submitting an issue to the Backdrop Contributed Module Issue Queue. The queue is monitored for new applicants. After being accepted, you will be able to create a new project (or move an existing one) under the Backdrop Contrib group at http://github.com/backdrop-contrib.
Contributing to an existing project
The process for contributed projects is similar to that for Backdrop core and involves:
- Forking the repository on Github into your own account.
- Cloning the repository to your own computer.
- Modifying the code.
- Committing and pushing the code to your repository.
- Making a pull request back to the original project.
Automated testing is not (yet) available. If the project you are contributing to includes tests, it is nice to run these in your browser locally by enabling the "SimpleTest" module and then visiting admin/config/development/testing to run the tests for the project.
Courtesy in contributing code
Note that all contributors to Backdrop projects are added to the "Authors" group of the "Backdrop CMS contributed projects repository" which means that anyone, once granted initial permission, has access to modify issues and labels for all projects in backdrop-contrib. Please use this power responsibly.
Contributed development branches
Contrib branches should reflect the core major version (1.x) followed by a hyphen and then your module's major version (1.x). For example 1.x-2.x indicates it is the 2.x version of a module made for Backdrop 1.x.
Contributed releases
Once you have created a module, theme, or layout for Backdrop and added it to the contrib group on GitHub, you'll likely also want it to appear on backdropcms.org. In order to do this, you'll need to create an official release of your project.
When making official releases of your project on GitHub, please follow the same semantic versioning patterns used by Backdrop core, but also include a prefix indicating the version of Backdrop core in which the project is compatible. Contrib release tags should include the core major version followed by a hyphen and then your module's major.minor.patch number. For example 1.x-1.0.0 indicates it is the 1.0.0 release of a project that is compatible with Backdrop 1.x. See the devel module releases for a real-world example.
Steps to create an official release are as follows:
- Post your module, theme, or layout in the contrib group on GitHub
- Test thoroughly, be sure everything works as intended.
- Create a tag for your release, name it semantically, for example: 1.x-1.0.0
- Push your tag up to GitHub
- On GitHub, visit the releases tab for your project.
- edit the tag you just pushed up.
- Add a release title, description, and click the "Publish release" button to create your release.
Your new release should be packaged by the Backdrop CMS packing script within seconds. If the packager succeeds, a package named "Download [Project]" will be added to the release on GitHub, and almost as quickly, it will also appear on backdropcms.org. If the packager fails, an error message will be attached to the release instead of the packaged download.
Your module's project page will show a download under "Recommended releases" and possibly one or more under "Other releases", as here:
Each project has a recommended major version, which will start out as the major version of your first release. The "Recommended releases" download is the highest-numbered release with the recommended major version. "Other releases" are the highest-numbered releases of each non-recommended major version.
New major version releases are not automatically recommended; it is not uncommon for the first release of a new major version to be an alpha or beta release for testing, for example. When you want to change the recommended major version, post a request in our Zulip chat, and one of the site administrators will make that change.
By default, the highest-numbered release of all major versions are considered to be supported, however, an older major version can be marked "unsupported" and this will show up as such in the modules listing on any websites on which the module is installed after an update check. To mark an older major version as unsupported, please post a request in our Zulip chat, and one of the site administrators will make that change.