Backdrop delivers features quickly with frequent "minor" releases every 4 months, on the following dates:

  • Jan 15th
  • May 15th
  • Sept 15th

APIs will move slowly over longer, "major" release cycles that happen every 3 years or more. Backdrop encourages everyone to upgrade through the new features it delivers. On our Roadmap page, you can see a summary of the changes and features added to past releases as well as what we are planning for future releases. For a more detailed changelog of all releases, see the release history on Github.

Version Numbers

Backdrop uses semantic versioning (which is also used by Drupal 8). Take a closer look at version 1.2.4, for example:

1.2.4

Major

Incompatible API changes
(3 years)

Minor

Backwards-compatible feature and API additions
(4 months)

Patch

Backwards-compatible bug fixes
(as-needed)

The whole thing is based on the http://semver.org model. In "plain English", user experience or developer experience improvements (tagged as [UX] and [DX] respectively on GitHub) with no functionality change, i.e. changing a string of help text on a field (may require updating of existing tests) can go into any bug fix release, minor release or major release. So an increment from 1.5.1 to 1.5.2 for example could fit this example.

Improvements that require a change in functionality (and therefore new tests for that functionality) need to wait for a minor release. This would be an increment for example of the middle number like from any 1.5.x release to 1.6.0.

Improvements that change/break an API that downstream developers are relying on in contrib or custom modules in Backdrop sites require a major release from 1.x.y to 2.0.0.

Branch Management

The amount of work can be kept to a minimum by organizing development branches cleverly with Git. Bugs will be fixed in the patch release version first, which is merged into the minor release, which in turn is merged into the major release. This means when fixing bugs, the fix is made to the production version of the software first, and then merged in to the future version.

Release cycle branch management diagram.
"Current version first" branch management, where features and bug fixes are added to the current ("Primary") version while continuously being merged into the future version. Note that to save space, the "patch" versions for the 2.x branch are not shown.

Timeline

Minor releases

Minor releases that provide new features, API additions, and significant UX improvements will be made every 4 months on the 15th of January, May, and September.

There is a two-week feature freeze that precedes each minor release, during which no new features will be committed. This helps to focus development efforts on testing changes of features that did get committed, and also fixing technical issues. Minor UX improvements, string changes, and bug fixes are still allowed during feature freeze.

Patch releases

Bug-fix releases will be made as necessary to fix any technical issues that have been identified in previous versions, and may contain some small UX changes. Since no features will be introduced or fundamentally changed, they are usually released when ready and not scheduled ahead of time.

Security releases are made shortly after any vulnerabilities have been identified and a technical fix has been prepared. Details about any vulnerabilities that have not been publicly disseminated will be embargoed until a scheduled release date (concurrent with Drupal when applicable) and announcements will be made ahead of time to notify site maintainers that they will need to take action.

Learn more about our security process and subscribe to security notifications.

Major releases

Any changes to core features or APIs that would break currently-installed Backdrop sites are reserved for major releases, in order to give site owners and contributed module developers time to upgrade their code and systems to work with the new platform.

No major releases are currently planned, but in the future they may happen every 3 or more years as the needs of our users evolve over time.

After a major version is released, only minimal changes will be made to previous versions of Backdrop, although security releases will continue to be provided for all supported branches whenever a vulnerability is identified.

API Compatibility

Backdrop aims to provide API-compatibility even as new features are added within a major version. However, due to the number of publicly available APIs with Backdrop, absolute compatibility is not realistic. In this case, API compatibility within a major version means no modifications to the following:

  • The signatures of public functions (those not starting with underscores).
  • The signatures of protected and public methods on classes and interfaces.
  • All hooks and their signatures.
  • The HTML markup of front-facing (non-admin) callbacks and templates, and the contents of their variables.
  • Form API element properties as specified by their corresponding hook_element_info() implementation.

However the following things may be changed, even in a minor release:

  • The signatures of private functions (those starting with underscores)
  • The signatures of private methods on classes.
  • The complete detail of $form (or other renderable) arrays, as exposed to hook_form_alter() implementations.
  • Database and configuration schemas.
  • Settings available in settings.php.
Portions of this page modified from Semantic versioning for Drupal 8.x proposal.