Яку "конвенцію про іменування версій" ви використовуєте? [зачинено]

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

Особисто я віддаю перевагу номеру складання у шістнадцятковій (наприклад, 11BCF), це слід збільшувати дуже регулярно. А потім для клієнтів простий тризначний номер версії, тобто 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

Я рідко повністю погоджуюся з Джеффом Етвудом, але я схильний дотримуватися його думки щодо .NET-конвенції про нумерацію версій .

(Основна версія). (Незначна версія). (Редакційний номер). (Номер збірки)

Частіше за особисті проекти я вважаю це зайвим. Декілька разів, коли я працював над істотними проектами, такими як пошукові системи в C #, я дотримувався цієї конвенції і міг ефективно використовувати її як внутрішній трекер.

Сюжетна версія ( http://semver.org/ ) заслуговує на згадку тут. Це публічна специфікація для версійної схеми у вигляді [Major].[Minor].[Patch]. Мотивація цієї схеми полягає у спілкуванні сенсу з номером версії.

Я не користуюся ним, але я бачив, і це цікава структура:

Рік. Місяць. День

Самостійно пояснив.

Я намагаюся використовувати політику раціональної версії RubyGems, в якій:

• При порушенні бінарної сумісності число основної версії збільшується
• Невеликий номер версії збільшується, коли додається нова функціональність
• Змінення номера збірки для виправлень помилок.

Ось дуже тонкий підхід до нумерації версій:

• N.x.K, де Nі Kцілі числа. Приклади: 1.x.0, 5.x.1, 10.x.33. Використовується для проміжних будівель .
• N.M.K, Де N, Mі Kцілі числа. Приклади: 1.0.0, 5.3.1, 10.22.33. Використовується для випусків .
• N.x.x, де Nціле число. Приклад: 1.x.x. Використовується для гілок підтримки .
• N.M.x, де Nі Mцілі числа. Приклад: 1.0.x. Використовується для випуску гілок .

Ось малюнок для простої ілюстрації підходу до нумерації версій:

PAозначає пре-альфа A означає альфа B означає бета AR означає альфа-випуск BR означає бета-випуск RC означає, що випуск кандидат ST означає стабільний

Переваги такого підходу до нумерації версій полягають у наступному:

• Він відображає специфіку спритного життєвого циклу розробки програмного забезпечення .
• Він враховує специфіку структури сховища вихідного коду .
• Це самостійно пояснює тим, хто звик до моделей. Кожен візерунок представляє різні артефакти. Такі шаблони можна легко проаналізувати та використовувати для інших цілей, таких як відстеження проблем.
• Набір моделей версій, які є основними для описаного підходу до версій, можна використовувати для збору показників та планування .
• Він орієнтований на поняття зрілості та рівня якості . Дуже часто такі версії, як 1.0.0, присвоюються без особливої ​​необхідності (коли програмне забезпечення знаходиться в глибокій альфа). Представлений підхід до нумерації версій дозволяє встановити кілька рівнів зрілості. У найпростішому випадку він матиме лише два рівні: проміжний build ( N.x.K) та release ( N.M.K). Випуск означає, що частина програмного забезпечення з повним номером версії ( N.M.K) пройшла якийсь процес управління якістю в компанії / організації / команді постачальника.
• Це свідчення гнучкості як розробки, так і тестування.
• Заохочує модульний підхід до структури та архітектури програмного забезпечення.

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

Особисто моє ставлення до використання версії дати замість реальних номерів версій передбачає, що розробники програмного забезпечення з датованими версіями:

• Нічого не знайте про життєвий цикл розробки програмного забезпечення . Розвиток зазвичай спритний і ітеративний. Підхід до нумерації версій повинен представляти ітераційний характер процесу розробки програмного забезпечення.
• Не дбайте про якість програмного забезпечення . Контроль та забезпечення якості є спритними та ітеративними. Так само, як розвиток. А номер версії повинен бути свідченням гнучкості та ітеративного характеру як розвитку, так і контролю / забезпечення якості.
• Небайдужа архітектура чи ідея їх застосування. Основний номер версії ( Nin N.M.K) відповідає як за архітектурне рішення, так і за основоположний принцип програми. Основний номер версії Nповинен бути змінений відповідно до змін в архітектурі або змін основних ідей та принципів її роботи / функціонування.
• Не мають контролю над їх базою кодів . Напевно, є лише одна гілка (стовбур) і вона використовується для всього. Що особисто я не вважаю правильним, оскільки це закликає кодову базу стати одним великим сміттєзвалищем.

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

Для кожної основної версії, яку ви випускаєте, не рідкість є робоча версія, яку ви називаєте її внутрішньо. Наприклад, на моєму останньому робочому місці ми посилалися на основну версію з наступною конвенцією про іменування:

[хворий стан] [алітеративна назва тварини]

Який дав такі назви, як « Лімбовий Лампрей », « Поранена вомба » та « Астматичний антеатр ».

Переконайтесь, що якщо це справді класне ім’я, воно не просочується до ваших клієнтів.

Покоління.Version.Revision.Build (9.99.999.9999)

Покоління рідко змінюється. Лише велика черга на продукт: DOS -> Windows, повне реінжиніринг.

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

Часто проводиться ревізія (незначні функції та виправлення помилок).

Збірка - це внутрішня інформація.

git describeнадає приємне розширення до обраної вами конвенції про нумерацію. Досить просто вставити це в процес збирання / упаковки / розгортання.

Припустимо, ви назвали свої версії з маркованим випуском ABC (major.minor.maintenance). git describeна даному комітеті знайдеться останній позначений пращур комітету, потім позначте кількість комітетів з тих пір і скорочене SHA1 комітету:

1.2.3-164-g6f10c

Якщо ви насправді є однією з версій, звичайно, ви просто отримаєте тег (1.2.3).

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

Major.Minor.Public (build) [альфа / бета / пробна версія], наприклад "4,08c (1290)"

• Основний номер версії (1, 2, 3 ...)
• Неповнолітній - це двозначна версія другорядного (01, 02, 03 ...). Зазвичай десяткову цифру збільшують, коли додаються значні нові функціональні можливості - ті, що стосуються лише виправлень помилок.
• Публічний - це публічний випуск збірки (a, b, c, d, e), який часто відрізняється від другорядної версії, якщо незначна версія ніколи не випускається як публічне оновлення
• build, будучи фактичним номером збірки, який компілятор відслідковує.
• із TRIAL, ALPHA, BETA X або RC X, доданими до цих особливих випадків.

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

Я використовую .NET, тому я застряг із системою нумерації версій .NET, але я намагаюся надати семантичний сенс цифрам, так що

major.minor.build.revision

• major = (до проекту)
• другорядний = (до проекту)
• build = номер збірки з Хадсона (ви можете використовувати TeamCity або TeamBuild тощо) тут
• редакція = підривна або базарна ревізія (залежно від проекту та використання його)

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

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

Вся справа в простежуваності!

Ми використовуємо Major.Minor.Build # .YYMMDD [суфікс], оскільки ми зазвичай робимо лише одне виробництво в будь-який конкретний день (але використовуємо суфікс ab / c / d, якщо їх більше), а YYMMDD надає користувачам / клієнтам / управління вказівка ​​віку збірки, де 6.3.1389 цього немає.

Основна кількість збільшується зі значними особливостями продукції (оплачується).

Невеликі числа збільшуються за допомогою виправлень / удосконалень (безкоштовне оновлення).

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

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

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

Мені особисто подобається семантична версія :

• Релізи є Major. Minor.Patch
• Patch з кроком щоразу, коли ви випускаєте збірку.
• Minor з кожним додаванням сумісної функціональності.
• Major з кроком, коли нова функціональність не сумісна назад.
• Коли Major== 0 ви перебуваєте в альфа / попередньому випуску. Major> = 1 - це ваші публічні випуски.
• Нижчі номери скидаються на 0 щоразу, коли ви збільшуєте, так

  1.5.3-> 1.5.4(виправлення помилки) -> 1.6.0(незначна функція) -> 2.0.0(порушення зміни)

              1.0.0
                |
              1.0.1
                |
(загальнодоступний 1.0) 1.0.2 -----
                | \
              2.0.0 1.1.0
                | |
              2.0.1 1.1.1 (загальнодоступна 1.1)
                |
(загальнодоступний 2.0) 2.0.2 -----
                | \
              3.0.0 2.1.0
                         |
                       2.1.1 (загальнодоступний 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Z- наш внутрішній номер версії. X.Yномер публічної версії, той, який має значення для наших клієнтів. Коли X.Y.Zверсія стає загальнодоступною, версія ніколи не буде X.Y.(Z+1): публічна версія завжди є останньою з серії.

X збільшується, коли виходить основна версія.

Y використовується для гілок обслуговування цих основних випусків, лише для виправлень помилок.

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

В якості бічної примітки ми використовуємо maven (з releaseкомандою) для збільшення номера версії. Отже, є і X.Y.Z-SNAPSHOTверсії (що вказує на будь-яку версію між X.Y.(Z-1)і X.Y.Z).