Bump версія перед початком нової розробки або під час тегування випуску, що краще?

Деякі проекти нарікають версію перед початком нової розробки, а інші проекти підписують версію під час тегування випуску.

Який підхід кращий?

Якщо номер версії не змінився на початку нової фази, розробники можуть забути змінити її та просто випустити програму.

Якщо номер версії змінився перед випуском тегів, то 2 номери версій (тег та Makefile / AssemblyInfo.cs) не збігаються.

git describe може дати вам v1.2.3.4-15-g1234567, якщо поточна редакція після v1.2.3.4, але ви вже змінили файли, щоб мати v1.2.3.5

Основна причина номера версії полягає в тому, що коли виявлена ​​помилка, ви зможете налагоджувати, використовуючи фактичну версію вихідного коду, в якій насправді сталася помилка (таким чином, виявляєте справжню причину помилки).

Не має значення, якою схемою версій ви користуєтесь, поки користувач вашої продукції може повідомити розробнику достатньо інформації, щоб розробник міг досягти цієї мети.

Інші причини версій - маркетингові та довідкові (іноді юридичні) команди.
Ці команди мають свій пріоритет для версій.

• Допомога
  Хоче простий спосіб визначити сумісність та функції та потенційно стабільність (див. Схему чисел чи непарних чи парних чисел Linux).
• Маркетинг
  хоче кожен раз більше (бажано вище 2)
• Юридичний
  Хоче переконатися, що у вас є всі функції, перед якими збільшується кількість.

У всіх випадках застосовувана схема є неважливою. Поки ви послідовні (або у вас є легко доступна високодокладна документація про зміну значень).

Коли використовуються чотирисегментні номери версій, такі як .NET-збірки, я вважаю за краще використовувати тег управління версіями для встановлення перших трьох сегментів, тоді четвертий сегмент - це кількість комітів з цього тегу.

Наприклад, версія отримує тег "v1.2.3". Якщо git-describeповертається "v1.2.3-4-g1a2b3c4", тоді при побудові ця збірка стає розробленою як 1.2.3.4.

Якщо тег буде застосовано пізніше до цієї версії, то git-describeзамість цього повернеться "v1.2.4", що представляє версію 1.2.4.0. Наступним зобов’язанням буде 1.2.4.1.

Переваги, які я отримую від цієї системи, є:

• Кожна фіксація автоматично збільшує номер версії.
• Версію можна зробити «.0» випуском, просто позначивши її.
• Хоча це не ідеально, ця система працює з DVCS, оскільки вона підраховує кількість комісій з часу останнього тегу.