У меня есть проект, в котором разработка ведется на master
ветка. В определенные моменты мы переходим на ветку релиза, такую как 2.1.x
, В такой ветке у нас есть несколько коммитов, завершающих выпуск 2.1.0 в течение нашего периода RC. А после выпуска 2.1.0 мы могли бы сделать бэкап для исправлений и сделать дополнительные выпуски 2.1.x.
Понятно, что 2.1.x
правильное имя ветки, как только вышла 2.1.0. Однако правильно ли это раньше, пока нет стабильной версии 2.1.0? Или ветка должна называться 2.1.x-dev
а потом будет переименован как только 2.1.0 помечен?
Ветка автоматически имеет только стабильность разработки.
Рассматривайте это как недостаток или преимущество в зависимости от того, чего вы хотите достичь: программное обеспечение, которое использует пакет и не допускает стабильности dev, не будет устанавливать зависимости этого пакета, если они нестабильны — даже если этот пакет зависит от чего-то вроде » 2.1.0@dev «явно.
Недостатком является то, что вы не сможете напрямую установить эту зависимость, вам придется явно разрешить ее:
"minimum-stability": "dev"
чтобы разрешить КАЖДОЕ требование к версии для установки стабильности dev (что, вероятно, приведет к огромному беспорядку и поломкам), так"prefer-stable": true
Теперь о номерах версий ветви: ветка должна иметь номер версии, который она должна иметь, когда она является стабильной версией x.y.0.
Без помеченной версии, требование 2.1.0@dev
установит последний коммит ветки 2.1.x при использовании методов выше. В случае версий с тегами косвенные зависимости станут удовлетворительными, если это позволит минимальная стабильность, т. Е. Если основное программное обеспечение позволяет устанавливать пакеты RC, будет установлена любая версия с тегами, такая как 2.1.0RC3 или финальная версия 2.1.0.
Обратите внимание, что установка веток — все равно что пытаться нацеливаться на движущиеся цели Имена ветвей, содержащие версии, немного лучше, чем использование «dev-master», но все же допускают разумное количество конфликтов. Попробуйте использовать теговые версии в любое время для производственного программного обеспечения — не имеет значения, являются ли версии альфа, бета, RC или окончательными, тег должен указывать на определенный коммит и вписываться в схему семантического контроля версий (т. Е. Должен не вносить обратно несовместимые изменения как исправление).
Других решений пока нет …