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

Ответ 1

Существует Семантическая версия, автор Tom Preston-Werner из славы github:

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

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

• При пометке выпусков в системе управления версиями тег для версии ДОЛЖЕН быть "vX.Y.Z", например. "V3.1.0" .

Ответ 2

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

• v1.2.3
• 1.2.3

Преимущества v1.2.3 заключаются в том, что документация Git (а также документация Mercurial) использует этот формат в своих примерах и что несколько "полномочий", таких как ядро ​​Linux, Git, и упомянутый Semantic Versioning.

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Когда мы готовы к выпуску, мы помечаем его, а затем снова объединяем в последний раз, и мы называем тег с тем же именем, что и ветка, но с дополнительным идентификатором о том, какая именно версия, например. "1,6-релиз" или "1,6-бета" или "1,6-rc2" и т.д.

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

Ответ 7

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

VERSION = `git describe --tags`

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

Ответ 8

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

• 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 -prefixed.. см. также ответ @VonC)