Могут ли номера версий модулей быть только числовыми?

Как объяснил Мариус, Magento использует функцию version_compare(). Документация описывает, как это работает:

Функция сначала заменяет _, - и + точкой. в версии строки, а также вставляет точки. до и после любого не-числа, так что, например, "4.3.2RC1" становится "4.3.2.RC.1". Затем он сравнивает части, начиная слева направо. Если деталь содержит строки специальной версии, они обрабатываются в следующем порядке: любая строка, не найдено в этом списке . Таким образом, можно сравнивать не только версии с разными уровнями, такими как "4.1" и "4.1.2", но и любую конкретную версию PHP, содержащую состояние разработки.

Что это значит для ваших примеров?

• 1.1.2-devmaster нормализуется на 1.1.2.devmaster
• 1.1.2-branch-foobar нормализуется на 1.1.2.branch.foobar
• Для сравнения недостающие части заполнены нулями (это явно не указано в документация. Это гарантирует, что 1.0 < 1.0.1)
• 1.1.2.devmaster.0 > 1.1.2.branch.foobar потому что в соответствии с порядком devmaster = branch и foobar < 0

Еще несколько примеров:

• 1.1.2 > 1.1.2-devmaster потому что devmaster < 0
• 1.1.2-dev-master = 1.1.2-dev-foobar потому что master = foobar
• 1.1.2-dev-master > 1.1.2-branch-foobar потому что dev > branch и master = foobar (см. Особое значение "dev")

Каковы практические последствия?

Хотя вы можете использовать произвольные строки, они могут вести себя не так, как вы ожидаете, если вы не используете стандартный формат.

Быть особенно осторожно со сценариями обновления. Некоторые разные строки будут рассматриваться как равные, другие - нет. Сценарии обновления запускаются только в том случае, если старая версия меньше новой версии.

Так, например, можно создать сценарий обновления upgrade-1.1.2-branch-foobar-1.1.2.php, но не upgrade-1.1.2-branch-foobar-1.1.2-branch-master.php

Почему вы хотите это сделать?

Я не вижу смысла в определении такой версии, как dev-master. В composer это динамическая версия, которую вы можете требовать в качестве зависимости, но она всегда сопоставляется с реальная версия (или, по крайней мере, реальная фиксация), вы никогда не определили бы ее как номер версии пакета.

Возможно, вам захочется попробовать использовать суффиксы ветвей, чтобы предотвратить конфликты, возникающие при обновлении версии в двух ветвях одновременно. Таким образом, вместо двух сценариев upgrade-1.0.0-1.0.1.php, которые необходимо тщательно объединить, у вас будут upgrade-1.0.0-1.0.0-feature-foo.php и upgrade-1.0.0-1.0.0-feature-bar.php, а затем при объединении ветвей функций вы добавите upgrade-1.0.0-feature-bar-1.0.1.php и upgrade-1.0.0-feature-foo-1.0.1.php, чтобы применить соответствующие отсутствующие сценарии обновления к каждому филиал.

Это классная идея, но она не сработает. Вот почему: Сценарии обновления собраны в Mage_Core_Model_Resource_Setup таким образом, доступные сценарии упорядочиваются с использованием version_compare() в первой строке версии в имени файла. Нет никакого сравнения равенства с текущей версией, кроме как с version_compare. Это означает, что 1.0.0-feature-bar и 1.0.0-feature-foo рассматриваются одинаково, и если вы находитесь в одной из этих версий и у вас есть сценарии, упомянутые выше, не определено, какой из них казнен.

Кроме того, сценарии обновления должны содержать ровно одну черточку - после upgrade-, которая используется для разделения между версией и версией. Но вы могли бы обойти это с помощью строк нормализованной версии upgrade-1.0.0.feature.bar-1.0.1.php.