Чи існує стандартна угода про іменування git тегів? [зачинено]

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

Версія 1.0.0 семантичної версії Тома Престона-Вернера з 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 можуть автоматично запропонувати тарбол або zip-завантаження форми packagename-$tag.tar.gz(і я думаю, цілком встановлено, що тарбол не повинен називатися package-v1.2.3.tar.gz). Крім того, ви можете git describeбезпосередньо використовувати для генерування номерів версій tarball. Для легких проектів без формального процесу випуску ці можливості можуть бути досить зручними. Слід також зазначити, що семантична версія не є єдиним або загальновизнаним стандартом нумерації версій. І помітні проекти, такі як GNOME, а також незліченна кількість інших проектів використовують 1.2.3іменування тегів.

Я думаю, що, мабуть, вже пізно консолідувати ці позиції. Як завжди, будьте послідовними та маєте сенс.

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

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

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

Нова порада менеджерів пакетів для тегів версій без префіксу v(як композитор для 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-реліз" або "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)