Коли ви змінюєте свій основний / другорядний / номер версії для виправлення?

Можливий дублікат:
якою «умовою іменування версій» ви користуєтесь?

Чи змінюєте ви свої основні / другорядні / номери версій виправлень безпосередньо перед випуском чи відразу після?

Приклад: Ви щойно випустили у світ 1.0.0 (huzzah!). Але чекай, не святкуй занадто багато. 1.1.0 виходить за шість тижнів! Таким чином, ви виправите помилку і зробите нову збірку. Як називається ця збірка? 1.1.0.0 або 1.0.0.xxxy (де xxxy - кількість збірки, що збільшується 1.0.0)?

Майте на увазі, що у вас може бути 100 функцій і помилок, щоб перейти в 1.1.0. Тож може бути добре називати це 1.0.0.xxxy, оскільки ви ніде не близькі до 1.1.0. Але з іншого боку, інший розробник може працювати на 2.0.0, і тоді ваш збір може бути краще названий 1.1.0.0 та його 2.0.0.0 замість 1.0.0.xxxy та 1.0.0.xxxz відповідно.

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

Чому?

Припустимо, ви дотримуєтесь такої схеми, як Semantic Versioning , і у вас є номер збірки у версії. Тож у вас може бути [майор]. [Мінор]. [Патч]. [Збірка]. Я зателефоную [майору]. [Мінор]. [Патч] частину версії.

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

Якщо ви готуєтесь до випуску, і програмне забезпечення проходить усі його тести, ви не хочете переробляти та повторно перевіряти програмне забезпечення лише тому, що вам довелося оновити версію. Коли ви зрештою робите реліз, ви заявляєте, що "build 1.1.0.23" відтепер буде називатися "версія 1.1.0".

Модель приросту після випуску має сенс і для розгалуження. Припустимо, у вас є галузь розробки основних напрямків, і ви створюєте гілки обслуговування випусків. Щойно ви створюєте відділення випуску, ваша галузь розвитку більше не пов’язана з номером версії цього випуску. Гілка розробки містить код, який є частиною наступного випуску, тому версія повинна відображати це.

Як правило, я намагаюся використовувати SemVer для внутрішніх номерів версій. Приємно мати можливість знати щось про випуск на основі семантики номера його версії.

Під час розробки я намагаюся відразу змінити номери версій (якщо це можливо) . Іноді важко дізнатися, чи буде ця зміна переломною чи ні (що вплине на номер моєї версії), тому нічого не "встановлено в камінь".

Щоб вирішити ваш конкретний приклад:

• Під час розробки версії до випуску будуть 1.0.1-alpha.1, 1.0.1-alpha.2 тощо.
• Остаточним випуском виправлення помилок буде версія 1.0.1.

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

Припустимо, ABCD у відповідях. Коли ви збільшуєте кожен із компонентів?

Це в основному визначається політикою вашої компанії. Наша політика компанії:

• A - Значні (> 25%) зміни або доповнення в функціональності або інтерфейсі.
• Б - невеликі зміни чи доповнення у функціональності чи інтерфейсі.
• C - незначні зміни, які порушують інтерфейс.
• D - виправляє збірку, яка не змінює інтерфейс.

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

Основні та незначні кількості збірок (c і d у abcd) зазвичай контролюються розробкою. c - номер збірки, а d використовується для виправлень певного випуску чи версії c.

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

Ми намагаємось наслідувати приклад Eclipse . Робити пояснення краще, ніж я можу, але для нас це працює так:

Коли ви випускаєте 1.0.0.0, номер версії, яку ви змінюєте, залежить від типу змін, які ви вносите.

• Реліз, що не впливає на API, розглянемо виправлення помилок за кадром, що змушує поточний API працювати очікуваним способом, випускається з версією 1.0.1
• Випуск, який додає API, але не змінює існуючий API, можливо, ви додали нову функцію, яка не робить поточних клієнтів незрівнянними з новою версією. Сюди також можна включити будь-яку кількість вищезазначених виправлень.
• Випуск розбиває поточний API, щось видаляє, щось змінює таким чином, що порушує порівнянність з поточними клієнтами. Це може також мати будь-яку кількість вищезазначених виправлень.

Щодо того, як використовувати 4-й розділ у номері версії, ми використовуємо це для диференціації різних збірок у Nuget (рішення управління пакетом, яке ми використовуємо для .net). Це дозволяє нам уникнути необхідності очищення кеш-пам'яті щоразу, коли нам потрібно оновлювати невідоме програмне забезпечення.

Наступної збірки немає. На тій гілці.

Ідеалізована версія нашої схеми.

Ідентифікація версії в будь-якій гілці - PRETTY_BRANCH_NAME-збірка, а PRETTY_BRANCH_NAME фіксується при створенні філії.

Наша схема розгалуження (*) така:

Гілки верхнього рівня, PRETTY_BRANCH_NAME - кодове ім'я, говорити про номер версії на цьому рівні безглуздо, може бути запланована схема, але вона зміниться до випуску.

• відділення ТНГ ( наступного покоління ), де здійснюється довгостроковий розвиток. Часто ми навіть цього не маємо, і він ніколи не (випускає) підгалузі.

• відділення TCG ( поточного покоління ), де робиться поточний розвиток. PRETTY_BRANCH_NAME - кодове ім'я.

• відділення TPG ( попереднього покоління ). Часто тут більше не розвивається, але в підгалузях може бути активність.

Підгалузь складається з гілки верхнього рівня (TCG, за наявності повільної міграції TPG), коли бета-версія для початку головного випуску. PRETTY_BRANCH_NAME - це щось на кшталт "1.3.X" (X - літера, а не цифра; це означає, що ми маємо намір надсилати звідси 1.3 випуски), зворотний зв'язок від бета-версії тут буде врахований, тоді як робота над наступним головним випуском проводиться на відділення TCG

В ідеалі випуск повинен бути знімком на цій гілці, але ми знаємо, що ми не ідеальні і часто потрібно робити зміни в останню хвилину, дозволяючи іншим продовжувати працювати над наступним незначним випуском. Таким чином, підрозділи виробляються для остаточної стабілізації з гарними назвами, що є офіційним номером версії (на той час навіть маркетинг не бажає змінювати її), як "1.3", "1.3.1" з гілки "1.3.X", остання збірка на кожному - це випуск.

Якби у нас був четвертий рівень, імена підрозділів були б "1.3.0.X", з яких у нас були б під ^ 3розгалуження "1.3.0.0" "1.3.0.1".

(*) На рівні випуску. На кожній з них можуть бути підгалузі проекту.

Якщо ви продаєте програмне забезпечення, то ви будете мати новий головний реліз кожного разу, коли продажі / маркетинг потребує отримання більшого бонусу :-).

Якщо у вас є контроль, виконайте вказані нижче дії.

1. Основні релізи, коли:

   • Існує деяка несумісність з попереднім випуском, який вимагає перетворення тощо, як з Python 2 в Python 3.

   • Є цілий шматок нового функціоналу.

2. Незначні випуски для будь-яких невеликих змін у функціональності.

3. Виправлення виправлень для виправлень помилок.