Существует ли стандартное соглашение о присвоении имен для тегов мерзавца? [закрытый]
5 ответов
Версия 1.0.0 Semantic Versioning, автор Том Престон-Вернер, известный в GitHub, имел суб-спецификацию , адресованную этому:
Спецификация метки (SemVerTag)
Эта суб-спецификация ДОЛЖНА быть использована, если вы используете систему контроля версий (Git, Mercurial, SVN и т.д.) для хранения вашего кода. Использование этой системы позволяет автоматизированные инструменты для проверки вашего упаковать и определить соответствие SemVer и выпущенных версий.
- При маркировке релизов в системе контроля версий тегом для версии ДОЛЖЕН быть "vX.Y.Z", например "v3.1.0".
Однако после обсуждения это было удалено и больше не присутствует в последней версии спецификации SemVer (2.0.0 на момент написания статьи). Позднее обсуждение в том же месте углубилось и привело к появлению новой Является ли "v1.2.3" семантической версией? будучи добавленным в FAQ в ветке SemVer's master, хотя на момент написания статьи (более 2-х лет спустя) это изменение все еще не присутствует в официально выпущенной спецификации .
Мы используем ветки и теги для работы с конкретными релизами, за которыми следует реальный релиз, соответственно:
o---o-----o---o---o--- ... master
\ / /
\ / /
o-------o--- ... 1.6 branch
Каждый разработчик принимает ментальное решение о том, применима ли работа, которую он собирается коммитировать, только для master или она также применима к ветке. Вы можете видеть, что изменения, вносимые в ответвление, сливаются обратно с ведущим, но некоторые изменения на ведущем никогда не пойдут в ответвление (т.е. те, которые не предназначены для релиза 1.6, в этом примере).
Когда мы готовы выпустить релиз, мы помечаем его тегом, а затем последний раз сливаемся обратно, и мы называем тег тем же именем, что и ответвление, но с дополнительным идентификатором о том, какая это конкретная версия, например, "1.6-релиз" или "1.6-бета" или "1.6-rc2", и так далее.
... ------o---o---o--o---o--- ... master
/ /
/ /
... ---o------(*)--- ... 1.6 branch
1.6-release
Не существует одной лучшей практики, о которой я знаю. Вот некоторые ссылки:
- http://web.elctech.com/?p=79
- http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html#production-tagging
В общем, версионирование (0.0.1, v0.2.1, ...), возможно, рука об руку с каким-то отслеживанием проблем можно считать правдоподобным подходом. (... хотя я обычно использую v-префиксные имена тегов ... см. также ответ @VonC)
Насколько я знаю, нет.
Но Git не допустит одновременного использования тэга и одноимённого ответвления, поэтому если у вас есть ответвление "1.1" для работы 1.1, не ставьте тэг "1.1", используйте, например, "v1.1"
] Я не знаю никаких стандартов. Я просто выбираю имена моих тегов так, что могу приклеить [
]. [VERSION = `git describe --tags`
] в моих сценариях построения. Итак, соглашение об именовании тегов на самом деле зависит от соглашения об именовании версий проекта.[
].