How packages are versioned in the ecosystem #

Contents #

1. Published versions never change
2. The last position counts on
3. Constraints in composer.json
4. Versions inside an extension
5. What this means for you

Published versions never change #

"A published tag is never changed: a fix for a problem in v6.0.14 or an earlier tag reaches you as the next release, not as a corrected copy of the old one" (SECURITY.md). The same holds for extensions (Tags are permanent).

The last position counts on #

"After 0.1.9 the next release is 0.1.10; only the last position counts up unless you decide otherwise" (Releases and version numbers). A plain alphabetical sort puts 0.0.4.10 before 0.0.4.8; sort with git tag --sort=version:refname or sort -V. Composer and Packagist compare each position as a number.

Constraints in composer.json #

The kernel's constraints use ~, which "lets the last position float: ~6.0.8 accepts 6.0.9 and 6.0.10 but not 6.1.0" (The default extension distribution). Velocity, for example, is required at ~0.0.4.57 (README.md).

Versions inside an extension #

An extension states its release number in ezinfo.php and extension.xml (Bumping ezinfo.php and extension.xml), so the about page shows which release is installed (About and package pages).

What this means for you #

• A version number always means the same code.
• To get a fix, upgrade to the next version.
• When you choose a version, look at the published tags sorted by version, not at memory.
• Your own constraints with ~ pick up fixes in the last position automatically on composer update.

Related pages #

• Packages
• Versioning rules
• How releases happen
• Choosing the next version
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.