Существует ли стандартное соглашение об именах для тегов git? [закрыто]

Я видел много проектов, использующих v1.2.3в качестве соглашения об именах теги в git. Я также видел некоторое использование 1.2.3. Есть ли официально одобренный стиль, или есть ли веские аргументы для их использования?

Версия 1.0.0 Semantic Versioning , созданная Томом Престоном-Вернером из GitHub, имела под-спецификацию, решающую эту проблему:

Спецификация маркировки (SemVerTag)

Эту под спецификацию СЛЕДУЕТ использовать, если вы используете систему контроля версий (Git, Mercurial, SVN и т. Д.) Для хранения своего кода. Использование этой системы позволяет автоматизированным инструментам проверять ваш пакет и определять соответствие SemVer и выпущенные версии.

1. При маркировке выпусков в системе управления версиями тег для версии ДОЛЖЕН быть «vX.YZ», например, «v3.1.0» .

Однако после обсуждения это было удалено и больше не присутствует в последней версии спецификации SemVer (2.0.0 на момент написания). Более поздняя ветка обсуждения в том же месте углубилась и привела к новой «v1.2.3» семантической версии? будучи добавлено в FAQ в SemVer в masterотрасли, хотя на момент написания (более 2 лет) это изменение до сих пор нет в официально опубликованной спецификации.

По-видимому, существует два доминирующих соглашения (при условии, что вы также придерживаетесь некоторого разумного стандарта для нумерации самих выпусков):

• v1.2.3
• 1.2.3

Преимущества в том v1.2.3, что документация Git (а также документация Mercurial) использует этот формат в своих примерах, и что некоторые «авторитеты», такие как ядро Linux и сам Git , используют его. (Упомянутое Семантическое Управление версиями использовало это, но больше не использует.)

Преимущества 1.2.3состоят в том, что gitweb или GitHub могут автоматически предлагать загрузку формы из архива или архива packagename-$tag.tar.gz(и я думаю, что вполне установлено, что тарбол не должен называться package-v1.2.3.tar.gz). Кроме того, вы можете использовать git describeнепосредственно для создания номеров версий тарбол. Для легких проектов без формального процесса выпуска эти возможности могут быть весьма удобными. Следует также отметить, что семантическое управление версиями ни в коем случае не является единственным или общепринятым стандартом нумерации версий. И известные проекты, такие как GNOME, а также бесчисленное множество других проектов действительно используют 1.2.3именование тегов.

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

Обновление: Как уже упоминалось в этом комментарии, GitHub теперь предлагает имя тарбола с убранным 'v' из тега.

Причина предыдущего 'v' является исторической. Старые SCCS (cvs, rcs) не могли различить идентификатор тега и номер редакции. Идентификаторы тегов были ограничены, чтобы не начинаться с числового значения, чтобы можно было обнаружить номера ревизий.

Не то, что я знаю о.
Но Git не разрешит тег и ветку с одним и тем же именем одновременно, поэтому, если у вас есть ветка " 1.1" для 1.1работ, не ставьте тег " 1.1", используйте, например, " v1.1"

Новые менеджеры пакетов советуют помечать версии без префиксов v(например, composer для проектов PHP). SemVer 2.0 не имеет ничего о спецификации тегов. Это сделано намеренно, чтобы избежать конфликтов. Однако рекомендуется добавлять префикс vв документацию и текстовые ссылки. В качестве примера формат v1.0.4вместо полного version 1.0.4или ver. 1.0.4достаточно многословный и элегантный в документации.

Мы используем ветки и теги для специфической для релиза работы, за которой следует фактическая версия, соответственно:

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

Каждый разработчик принимает умственное решение о том, применима ли работа, которую он собирается совершить, просто к выполнению, или она также имеет отношение к отрасли. Вы можете видеть, что изменения, внесенные в ветку, объединяются обратно в master, но некоторые изменения в master никогда не будут выполняться в ветке (то есть в этом примере не предназначенные для выпуска 1.6).

Когда мы готовы к выпуску, мы помечаем его, а затем объединяем обратно в последний раз и называем тег тем же именем, что и ветвь, но с дополнительным идентификатором о том, какая это конкретная версия, например «1.6-release». или "1.6-бета" или "1.6-RC2" и так далее.

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release

Я не знаю никаких стандартов. Я просто выбираю имена своих тегов, чтобы

VERSION = `git describe --tags`

в моих сборочных скриптах. Таким образом, соглашение об именовании тегов на самом деле зависит от соглашения о присвоении имен проекта.

Я не знаю ни одной лучшей практики. Вот несколько ссылок:

• 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)