Backdrop CMS includes an update utility to handle any necessary changes to the database schema or configuration. Typically after replacing an older version of a module with a newer one, or the Backdrop core directory, you'll need to check if any updates need to be run.
About minor and major version updates
Backdrop CMS follows a semantic versioning scheme: given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version for incompatible API changes,
- MINOR version for added functionality in a backwards compatible manner, and
- PATCH version for backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format, for example, 1.1.3-alpha1.
Consistent with semantic versioning, Backdrop uses the following terminology for a change of version:
- An Update is moving to the next minor (e.g. 1.1.y to 1.2.y) or patch version (e.g. 1.1.1 to 1.1.2).
- An Upgrade is moving the next major version (e.g. from 1.x.y to 2.x.y) and is a more involved process.
Non-Breaking changes
Minor and patch version updates should not break APIs. Any projects that depend on the code being updated should continue working as expected without needing to be updated at the same time.
For example:
- Updating Backdrop core from 1.2.2 to 1.2.4 should not require any module updates.
- Updating Backdrop core from 1.2.x to 1.3.x should not require any module updates.
- Updating Webform module from 1.x-1.2.3 to 1.x-1.2.4 should not require an update to webform_autocomplete.
- Updating Webform module from 1.x-1.2.x to 1.x-1.3.x should not require an update to webform_autocomplete.
Breaking changes
Major version upgrades may contain API changes. In many cases, projects that depend on the code being updated will also need to be updated at the same time.
For example:
- Updating Backdrop core from 1.x.x to 2.x.x will require updates to modules, themes, and layouts.
- Updating Webform module from 1.x-1.x.x to 1.x-2.x.x may require an update to webform_autocomplete.