Есть стандарт именования для теги в Git? [закрытый]

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

179
git git-tag

8 ответов

версия 1.0.0 от Семантическое Управление Версиями, Том Престон-Вернер из GitHub славы, had суб-спецификация обращаясь к этому:

Спецификация Тегов (SemVerTag)

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

  1. при пометке выпусков в системе управления версиями,тег для версии должен быть "vX.Y. Z "например" v3.1.0".

однако, после обсуждение Это было удалено и больше не присутствует в последняя версия SemVer spec (2.0.0 на момент написания). последующего обсуждения на том же месте пошел в большую глубину, и привел к новому Is " v1.2.- Семантическая версия? будучи добавил В FAQ в SemVer это master филиал, хотя на момент написания (более 2 лет спустя) это изменение еще нет В официально выпущенной спецификации.

138

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

  • v1.2.3
  • 1.2.3

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

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

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

Update: как упоминалось в этой комментарий, GitHub теперь предлагает смоляное имя с буквой " v " на бирке.

95

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

67

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

14

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

10

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

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

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

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

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

VERSION = `git describe --tags`

в моем сценарии. Таким образом, соглашение об именовании тегов фактически зависит от соглашения об именовании версий проекта.

6

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

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

1