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

Question

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

Answer 1

Версия 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 лет спустя) это изменение еще не присутствовало в официально выпущенной спецификации.

Answer 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' из тега.

Answer 3

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

Answer 4

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

Answer 5

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

VERSION = `git describe --tags`

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

Answer 6

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

Answer 7

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

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

Answer 8

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

• http://web.elctech.com/?p=79
• http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

Вообще, управление версиями (0.0.1, v0.2.1...) может быть, рука об руку с некоторым отслеживанием проблем может считаться вероятным подходом. (.. хотя я обычно использую vимена тегов с префиксом.. см. также ответ @VonC)