Нужно ли мне вручную просматривать мой модуль каждый раз, когда я использую часть основного кода Magento и добавляю строку require: ... в composer.json?
Да, каждый раз, когда вы используете в своем коде что-либо из основного модуля, вам нужно добавить его к требованиям вашего композитора. Поскольку вы, вероятно, хотите, чтобы порядок загрузки был после основного модуля, я бы также предложил добавить его в ваш module.xml
файл в разделе последовательности.
Или есть автоматизированный инструмент, который может сделать это для меня?
Я еще не сталкивался. Если есть, пожалуйста, дайте мне знать. Это должен быть довольно сложный инструмент, который, вероятно, потребует значительного охвата тестами, а затем запускает матрицу разных версий для создания рабочего набора.
Как мне указать версию для включения в мой composer.json? Должна ли это быть конкретная версия модуля, против которой я разработал? Или я должен был использовать какой-то подстановочный знак? Или мне нужно принять решение на основе компромиссов? Если да, то какие компромиссы связаны с указанием каждого стиля версии?
Параметры для определения номера версии
100.0.2
Работать только когда эта конкретная версия
100.0.*
*
является подстановочным и может быть заменен любым номером версии
100.0.0
, 100.0.1
, ...
,100.0.120
~100.0.2
Делает 2 групповой символ , который может идти только так 100.0.2
, 100.0.3
, ...
,100.0.120
^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,
на основе стабильности модуля. Как указано в документации, требование будет выглядеть примерно так:На основании вашего обновления это должно быть обновлено как:
Я не думаю, что есть какая-либо автоматизированная система для этого, но согласно документации очень важно следовать этому.
Но вы должны использовать PATCH, если в вашем модуле есть небольшие исправления ошибок.
Ссылаться на
Вы правы, ответ немного неясен, но вы можете видеть, что он был обновлен примерно через год. Но так оно и есть.
источник