Шукаєте кращих практик щодо нумерації версій залежних компонентів програмного забезпечення

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

Давайте будемо більш конкретними:

Програмний компонент A - це мікропрограмне забезпечення, яке працює на вбудованому пристрої, а компонент B - його відповідний драйвер для звичайного ПК (машина Linux та Windows). Вони спілкуються один з одним за допомогою користувацького протоколу. Оскільки наш продукт також орієнтований на розробників, ми запропонуємо стабільні та нестабільні (експериментальні) версії обох компонентів (прошивка закритого коду, а драйвер із відкритим кодом). Наша найбільша складність полягає в тому, як впоратися зі змінами API в протоколі зв'язку.

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

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

Тож ось наше рішення:

Ми плануємо слідкувати за широко використовуваною нумерацією версій major.minor.patch та використовувати парні / непарні незначні числа для стабільних / нестабільних версій. Якщо ми вносимо зміни в API, ми збільшимо незначну кількість.

Ця конвенція призведе до наступного прикладу:

Поточна стабільна галузь - 1,2,1, а нестабільна - 1,3,7. Тепер новий патч для нестабільних змін API, що призведе до того, що номер нової нестабільної версії стане 1.5.0. Після того, як нестабільна гілка буде вважатися стабільною, скажімо в 1.5.3, ми випустимо її як 1.4.0.

Я буду радий відповісти на будь-яке з пов’язаних нижче питань:

• Чи можете ви запропонувати найкращу практику вирішення описаних вище питань?
• Як ви вважаєте, наша "звичайна" конвенція гарна?
• Які зміни ви застосували б до описаної конвенції?

Номери версій IMHO схожі на назви продуктів; важливо тим, що вони видимі, але неважливі тим, що вони є прикрасою, а не вмістом.

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

Число версій монотонно збільшується.
Це, мабуть, найочевидніше очікування, і в той же час найменш вірогідне насправді. На перший погляд, користувач очікує, що версія 2.3.5 з'явиться після версії 2.2.17 і має ту саму чи кращу технологію. Але, звичайно, 2.3.x є галуззю розвитку , а 2.2.x є стабільним , а 2.3.5 фактично був випущений ще в 2004 році, а галузь 2.2 досі активно працює, а 2.2.17 була випущена лише минулого квітня і містить. .. ну, ви зрозуміли ідею. Ви можете просто назвати версію 2.2 "Картопля" за всім значенням, яке містить номер. Ласкаво просимо до версії " Картопля-17 " !!

Подібні версії можуть бути оновлені / сумісні
Якщо у мене на комп’ютері є версія 3.7, і 3.8 виходить із усіма новими блискучими фрозботами, я очікую, що з певним оновленням або виправленням чи іншим моїм, 3.7 може стати 3.8 без перерви. Але якщо я на 3.7, а ви випустите 5.2, я не такий оптимістичний. Звичайно, я б швидше був приємно здивований, ніж розчарований.

Перша цифра є важливою,
я б навіть не намагався згадувати це, якби Java не була настільки помітною, що плутає з цього приводу. Якщо б хтось не сказав вам, ви не очікували, що "Java 7" насправді була версія 1.7. І коли ви вперше почули це, ви майже напевно відповіли: " Що? .. Чому? "

Зрозуміло, що пурист скаже, що основний номер версії зміниться лише в тому випадку, якщо зміна платформи не буде сумісною із зворотною стороною. Але чи дійсно ви маєте намір відкинути сумісність колись ? Часто основні версії оборотів є маркетинговим рішенням, а не технічним; абсурдність Яви походить з обох таборів, що мають свій шлях одночасно, майже до комічного ефекту.

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

- EDIT -
я забув згадати це, але Калеб це чітко зазначив: Не використовуйте номери версій для позначення нічого важливого (наприклад, стабільного / нестабільного), не роблячи це в іншому випадку явним в іншому місці. Так, ви знаєте, що непарний незначний номер версії вказує на розвиток, але це робить одного з нас. "Нестабільний" випускник Debian - хороший приклад; або ви також можете використовувати абсолютно окрему назву продукту; "Frozbot 1.2" для назви вашого продукту та "Devbot 1.3" для вашої версії розробки.

Після того, як нестабільна гілка буде вважатися стабільною, скажімо в 1.5.3, ми випустимо її як 1.4.0.

Ні ні. Для нестабільних 1.5.3 стабільний повинен починатися з 1.6.0 (і 1.4.x щойно пропущено, якщо ви хочете використовувати Semantic Versioning)

Ви намагаєтесь використовувати одне значення для позначення двох окремих речей.

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

По-друге, ви намагаєтесь вказати, стабільна чи дана версія чи ні.

Це можна вказати і те і інше з одним «номером версії," так само , як деякі магазини будуть використовувати деякі схеми ціноутворення , щоб вказати , є чи елемент у продажу. Наприклад, ціни, які закінчуються на "3" у магазині біля мене, є кінцевими цінами продажу. Це добре працює для співробітників, які швидко дізнаються, як визначити ціну продажу, але це не чудовий спосіб повідомити клієнтам про продаж. З цієї причини вони також виставляють таблички біля предметів продажу. Ви можете зробити щось подібне, як, наприклад, зробити найменш значну цифру для стабільних випусків і зробити її незвичайною для експериментальних версій. Я думаю, що якщо ви збираєтеся випустити щось експериментальне, ви повинні чітко позначити це таким чином. Ви можете додати "X" на початку або в кінці рядка версії, наприклад:X.1.5.31.5.3.X. Ви можете навіть експериментальний номер версії після цього, щоб ви могли випустити кілька експериментальних версій, все на основі однієї базової версії: 1.5.3.X1, 1.5.3.X2.

Слід також враховувати , що існує давня традиція використання «альфа» і «бета» версія номери для вказівки версії , які не можуть бути стабільними або повним: 1.5.3a54. Переконайтеся, що у вас є вагомі причини відмовитися від цієї схеми, якщо ви вирішите зробити щось інше, тому що вам, ймовірно, доведеться пояснити що-небудь інше своїй спільноті розробників.

Я б запропонував використовувати формат major.minor.patch, використовуючи розширення "тег" для стабільних / нестабільних версій та певне значення основних та другорядних чисел:

major.minor.patch-stable|unstable

де

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

Таким чином залежність легко управляється і скаже кожному клієнту / користувачеві компонента, коли їм потрібно більше уваги приділяти новим версіям. Наприклад, якщо компонент A (1.1.0-стабільний) залежить від B (5.4.534-стабільний), а нова версія B належна (6.1.0-нестабільна), одразу відомо, що A доведеться змінити, можливо, істотно .

Мені дуже подобається те, як Hibernating Rhinos будує RavenDb у порівнянні з версіями - у них просто збільшується кількість збірок. Коли вони отримують стабільний, він стає помітним стабільним. Але все - кандидат у звільнення.