2

Is it a problem if I use module versions like

1.1.2-devmaster

or

1.1.2-branch-foobar

2

As Marius explained, Magento uses the version_compare() function. The documentation describes how it works:

The function first replaces _, - and + with a dot . in the version strings and also inserts dots . before and after any non number so that for example '4.3.2RC1' becomes '4.3.2.RC.1'. Then it compares the parts starting from left to right. If a part contains special version strings these are handled in the following order: any string not found in this list < dev < alpha = a < beta = b < RC = rc < # < pl = p. This way not only versions with different levels like '4.1' and '4.1.2' can be compared but also any PHP specific version containing development state.

What does this mean for your examples?

  • 1.1.2-devmaster is normalized to 1.1.2.devmaster
  • 1.1.2-branch-foobar is normalized to 1.1.2.branch.foobar
  • For comparison, missing parts are filled with zeros (this is not explicitly mentioned in the documentation. It makes sure that 1.0 < 1.0.1)
  • 1.1.2.devmaster.0 > 1.1.2.branch.foobar because according to the order devmaster = branch and foobar < 0

Some more examples:

  • 1.1.2 > 1.1.2-devmaster because devmaster < 0
  • 1.1.2-dev-master = 1.1.2-dev-foobar because master = foobar
  • 1.1.2-dev-master > 1.1.2-branch-foobar because dev > branch and master = foobar (see special meaning of "dev")

What are the practical implications?

While you can use arbitrary strings, they might not behave as you expect if you don't use a standard format.

Be especially careful with upgrade scripts. Some different strings will be treated as equal, others not. Upgrade scripts are only triggered if the old version is less than the new version.

So for example, it's possible to have an upgrade script upgrade-1.1.2-branch-foobar-1.1.2.php but not upgrade-1.1.2-branch-foobar-1.1.2-branch-master.php

Why would you want to do that?

I don't see a value in defining a version like dev-master. In composer, this is a dynamic version, which you can require as a dependency, but it always maps to a real version (or at least, a real commit), you would never define it as package version number.

You might want to try to use branch suffixes to prevent conflicts that happen when you update the version in two branches at the same time. So instead of two scripts upgrade-1.0.0-1.0.1.php that need to be merged carefully, you would have upgrade-1.0.0-1.0.0-feature-foo.php and upgrade-1.0.0-1.0.0-feature-bar.php and then when merging the feature branches, you add upgrade-1.0.0-feature-bar-1.0.1.php and upgrade-1.0.0-feature-foo-1.0.1.php to apply the respective missing update scripts to each branch.

This is a cool idea but it won't work. Here's why: The upgrade scripts are collected in Mage_Core_Model_Resource_Setup such that the available scripts are ordered using version_compare() on the first version string in the filename. There is no equality comparison with the current version other than with version_compare. This means, 1.0.0-feature-bar and 1.0.0-feature-foo are treated equal and if you are at one of those versions and have the scripts mentioned above, it's not determined which of them is executed.

Also, the upgrade scripts must have exactly one dash - after upgrade-, which is used to split between from-version and to-version. But you could work around that with using the normalized version strings upgrade-1.0.0.feature.bar-1.0.1.php.

3

From the technical point of view it works but I wouldn't recommend it. Magento compares module versions using version_compare() See this method: Mage_Core_Model_Resource_Setup::applyUpdates()

version_compare() 'compares two "PHP-standardized" version number strings'. If you start naming the versions like that ... it's an easy way to end up in chaos.

0

As far as I know Magento does use the numbers (version) to decide if the SQL installs need to be executed. With these kind of versions I don't think it can figure out if an update was installed

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.