Magento 2: Как задать зависимости «семантического управления версиями» в моем модуле composer.json

Разработка и развертывание Magento 2 включает формальный процесс управления версиями , когда основные и вспомогательные версии основных модулей Magento будут увеличены на основе изменений в обратно совместимых функциях.

Как мне, как разработчику модуля Magento, создать список требований в моем собственном файле composer.json? Нужно ли мне вручную просматривать мой модуль каждый раз, когда я использую часть основного кода Magento и добавляю require:...строку в composer.json? Или есть автоматизированный инструмент, который может сделать это для меня?

Как мне указать версию для включения в мой composer.json? Должна ли это быть конкретная версия модуля, против которой я разработал? Или я должен был использовать какой-то подстановочный знак? Или мне нужно принять решение на основе компромиссов? Если да, то какие компромиссы связаны с указанием каждого стиля версии?

Существует много высокоуровневых описаний этой функции, но очень неясно, какие практические шаги должен предпринять рабочий разработчик и / или каковы реальные последствия этих шагов.

Нужно ли мне вручную просматривать мой модуль каждый раз, когда я использую часть основного кода Magento и добавляю строку require: ... в composer.json?

Да, каждый раз, когда вы используете в своем коде что-либо из основного модуля, вам нужно добавить его к требованиям вашего композитора. Поскольку вы, вероятно, хотите, чтобы порядок загрузки был после основного модуля, я бы также предложил добавить его в ваш module.xmlфайл в разделе последовательности.

Или есть автоматизированный инструмент, который может сделать это для меня?

Я еще не сталкивался. Если есть, пожалуйста, дайте мне знать. Это должен быть довольно сложный инструмент, который, вероятно, потребует значительного охвата тестами, а затем запускает матрицу разных версий для создания рабочего набора.

Как мне указать версию для включения в мой composer.json? Должна ли это быть конкретная версия модуля, против которой я разработал? Или я должен был использовать какой-то подстановочный знак? Или мне нужно принять решение на основе компромиссов? Если да, то какие компромиссы связаны с указанием каждого стиля версии?

Параметры для определения номера версии

1. 100.0.2
   Работать только когда эта конкретная версия

2. 100.0.*
*является подстановочным и может быть заменен любым номером версии 100.0.0, 100.0.1, ...,100.0.120

3. ~100.0.2
   Делает 2 групповой символ , который может идти только так 100.0.2, 100.0.3, ...,100.0.120

4. ^100.0.2
   Позволит любой релиз вплоть до 101 так 100.0.2, 100.0.3, ..., 100.1.0,100.2.5

Для вариантов 2-4, если ваши настройки стабильности позволяют это, он также будет включать в себя такие версии, как 100.0.1-beta

Практическое использование

Вариант 1.) является наиболее осторожным, вы знаете, против какой версии вы разработали, и принимаете только работу с этой конкретной версией - ваш модуль может быть установлен только вместе с этим конкретным модулем в этой версии. Все другие попытки установки / обновления будут неудачными с сообщением составителя, подчеркивающим, что он не может найти устанавливаемый набор компонентов.

Вариант 2.) Я думаю, что можно рассматривать как не вариант, как описано в Варианте 3.), если вы используете его как ~100.0.0

Вариант 3.) Будьте совместимы, пока не введены новые функции

Вариант 4.) Будьте совместимы, пока не внесены критические изменения

Компромиссы

1 Ваше расширение работает только для 1 версии модуля Magento (технически, если в модуле нет никаких изменений, номер версии не должен увеличиваться и несколько версий проекта Magento могут теоретически включать в себя один и тот же модуль ядра Magento с одной и той же версией. Я не видел этого и, похоже, требует некоторых изменений процесса на стороне Magento (см. здесь). Поскольку вы так тесно связаны с 1 версией основного модуля Magento, у вас останется множество выпусков и версий вашего собственного расширения, если вы хотите оставаться совместимым.

3-4 Ваше расширение работает с несколькими версиями Magento, и вам не нужно выпускать разные версии вашего расширения каждый раз, когда Magento выпускает новую версию. Недостатком здесь является то, что вы заявляете о совместимости, даже если в Magento может быть внесено изменение, несовместимое с вашим собственным кодом. Этот риск реален, поскольку определение семантической версионности в Magento для их собственных выпусков модулей распространяется только на то, что помечено @apiаннотацией (подробнее об этом в этом выпуске GitHub ) с его ограниченной областью действия.

ТЛ; др;
100.0.2Будьте осторожны, много выпусков, чтобы поддерживать
^100.0.2семантическое управление версиями, как это должно работать, меньше выпусков для вас, но с более высоким риском из-за ограниченного объема @apiаннотированных классов и методов. Если у вас есть расширение, которое на 100% использует санкционированные классы и методы, это будет очевидным выбором.

Это может быть как 0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,на основе стабильности модуля. Как указано в документации, требование будет выглядеть примерно так:

"require": {
    "myexamplestore/product-bundle": "2.0.0-RC1",
    "myexamplestore/acme-extension": "~1.0"
    }

На основании вашего обновления это должно быть обновлено как:

"require": {
    "myexamplestore/product-bundle": "2.4.0-RC1",
    "myexamplestore/acme-extension": "~2.0"
    }

Я не думаю, что есть какая-либо автоматизированная система для этого, но согласно документации очень важно следовать этому.

Но вы должны использовать PATCH, если в вашем модуле есть небольшие исправления ошибок.

Ссылаться на

PATCH указывает на обратную совместимость исправления ошибок

Вы правы, ответ немного неясен, но вы можете видеть, что он был обновлен примерно через год. Но так оно и есть.