Magento software and Magento module releases have their own unique version number.
Software version format
A change in the version for the Magento software indicates a patch or feature release. This version change does not reflect the nature of the changes in the code base.
Module version format
version field in a modules
composer.json file specifies the module version and consists of three numbers in the following format:
The format follows Semantic Versioning rules:
- The MAJOR version increments when incompatible API changes are made.
- The MINOR version increments when backward-compatible functionality has been added.
- The PATCH version increments when backward-compatible bug fixes occur.
For pre-release versions, the format is:
MAJOR.MINOR.PATCH-<alpha | beta | rc>n
||Stability indicators, as described in the
||An increment number to distinguish releases of the non-stable versions|
Magento’s module versioning policy complies with the following specifications:
Where versioning is used
The software version can be found in the source code of any Magento component
or bundle, inside the
It can be declared as the version of the component:
Or it can be used to declare a dependency on a particular version of a component:
Version usage example
The following example shows how versions are used with composer to install software and third-party extensions.
This example uses several composer packages on the public GitHub to simulate a merchant site, 2 core Magento modules, and a third-party extension.
- Start by cloning the master branch from GitHub.
This sample in
composer.jsonstates this site is dependent on a release candidate of a simulated Magento 2.0 release.
- Run the
composer updatecommand. Core modules a & b are pulled down from the repository.
- Now the SI includes a third-party extension by adding the composer dependency. This extension trusts our BC and sets the appropriate version on the module-a core dependency.
composer updateand see the new extension downloaded.
- When Magento releases 2.0 GA, the SI updates the site
composer.jsonto the release version.
composer updateand notice the core modules were updated since RC1, but the extension remains unchanged because of BC policy. This step repeats with each subsequent release of Magento (2.1, 2.2, 2.3, etc.). Deprecation strategy and community communication happens in 2.3.
- Magento decides backward incompatible changes are allowed and does this as part of the upcoming release 2.4.
composer updateand notice that
acme-extensionis marked as incompatible.
- Based upon previous communication, the developer has updated the extension so the SI updates to the new extension version.
composer update. Updates to core modules are returned as third-party extensions.
Module version dependencies - Information about how your module can depend on the version of other modules.
Codebase changes - Information on how changes in a Magento module’s codebase affect versions.