Що зазвичай представляють числа у версії (тобто v1.9.0.1)?

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

У версії 1.9.0.1 :

• 1 : Основна редакція (новий інтерфейс, багато нових функцій, зміна концептуальних обставин тощо)

• 9 : Незначна версія (можливо, зміна вікна пошуку, додана 1 функція, колекція виправлень помилок)

• 0 : випуск виправлення помилок

• 1 : Номер збірки (якщо використовується) - ось чому ви бачите рамку .NET, використовуючи щось на зразок 2.0.4.2709

Ви не знайдете багато додатків, які опускаються до чотирьох рівнів, зазвичай 3 достатньо.

Існує специфікація семантичної версії

Це короткий огляд версії 2.0.0:

Враховуючи номер версії MAJOR.MINOR.PATCH, збільшуйте:

1. ОСНОВНА версія, коли ви вносите несумісні зміни API,
2. МІНОРОЖНА версія, коли ви додаєте функціональність у сумісному сумісному режимі, і
3. Версія PATCH, коли ви робите назад сумісні виправлення помилок.

Додаткові мітки для попереднього випуску та збирання метаданих доступні як розширення до формату MAJOR.MINOR.PATCH.

Він може бути дуже довільним і відрізняється від продукту до продукту. Наприклад, з розподілом Ubuntu 8.04 посилається на 2008 рік

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

major.minor [.підтримка [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

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

Наприклад, WordPress йде за цими напрямками:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 до 2.0 буде великим випуском - функції, зміни інтерфейсу, значні зміни в API, поломка шаблонів 1.6 та плагінів і т. Д. 2.0 до 2.0.1 буде незначним випуском - можливо, виправлення помилки безпеки. 2.0.2 до 2.1 буде значним випуском - нові функції, як правило.

Цифри можуть бути корисними, як описано в інших відповідях, але подумайте, як вони також можуть бути досить безглуздими ... Нд, ви знаєте, SUN, java: 1.2, 1.3, 1.4 1.5 або 5, тоді 6. У старій хорошій версії Apple II номери Щось. У наш час люди відмовляються від номерів версій і ходять з дурними іменами на кшталт "Feisty fig" (або щось подібне) та "hardy чапля" та "europa" та "ganymede". Звичайно, це набагато менш корисно, тому що вам не вистачить місяця юпітера, перш ніж ви перестанете змінювати програму, і оскільки немає очевидного впорядкування, ви не можете сказати, який новий.

У версії v1.9.0.1: Це явна схема версії, яка використовується, коли ви не хочете використовувати ім'я для попередніх випусків або будувати на зразок -alpha, -beta.

1: Основна версія, яка може порушити зворотну сумісність

9: Додавання нових функцій для підтримки вашої програми разом із зворотною сумісністю з попередньою версією.

0: Деякі незначні виправлення помилок

1: Номер збірки (номер перед випуском)

але сьогодні такої схеми версій ви не знайдете. Зверніться до Semantic Versioning [semver2.0] https://semver.org/

Номери версій зазвичай не представляють собою окремі компоненти. Для деяких людей / програмного забезпечення цифри є досить довільними. Для інших, різні частини рядка номера версії представляють різні речі. Наприклад, деякі системи збільшують частини номера версії, коли змінюється формат файлу. Отже V 1.2.1 - це формат файлів, сумісний з усіма іншими версіями V 1.2 (1.2.2, 1.2.3 тощо), але не з V 1.3. Зрештою, саме від вас залежить, яку схему ви хочете використовувати.

Зазвичай це:

MajorVersion.MinorVersion.Revision.Build

Це залежить, але типовим є представлення major.minor.release.build .

Де:

• major - це основна версія версії вашого програмного забезпечення, думаю. NET 3.x
• мінор - це версія другорядного випуску вашого програмного забезпечення, подумайте .NET x.5
• release - це випуск цієї версії, зазвичай помилки збільшуватимуть її
• build - це число, яке позначає кількість виконаних вами будівель.

Так, наприклад, 1.9.0.1, означає, що це версія 1.9 вашого програмного забезпечення після 1.8 і 1.7 і т.д., де 1.7, 1.8 і 1.9 певним чином зазвичай додають невеликі кількості нових функцій поряд із виправленнями. Оскільки це xx0.x, це початковий випуск 1.9, і це перша збірка цієї версії.

Ви також можете знайти хорошу інформацію в статті Вікіпедії з цього приводу .

Майор.Мінор.Бугс

(Або деякі варіанти цього)

Зазвичай помилки - це виправлення помилок, які не мають нових функціональних можливостей.

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

Основна - це зміна програми, яка або порушує стару функціональність, або настільки велика, що якось змінює те, як користувачі повинні використовувати програму.

Кожен вибирає, що хоче зробити з цими номерами. Я спокусився зателефонувати до випусків abc, оскільки це все одно досить нерозумно. Попри це, те, що я бачив за останні 25+ років розвитку, як правило, працює таким чином. Скажімо, ваш номер версії 1.2.3.

Значення "1" вказує на "основне" перегляд. Зазвичай це початковий випуск, велика зміна набору функцій або перезапис значних частин коду. Як тільки набір функцій буде визначений і принаймні частково реалізований, ви переходите до наступного номера.

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

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

Поза позицією "3"? У мене немає поняття, чому люди роблять подібні речі, це стає просто заплутаніше.

Зокрема, деякі з OSS там викидають все це з виходу. Наприклад, версія Trac 10 - це фактично 0.10.XX. Я думаю, що багато людей у ​​світі OSS або не мають довіри, або просто не хочуть оголошувати, що у них зроблено великий реліз.

З файлу C # AssemblyInfo.cs можна побачити наступне:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

release.major.minor.revision міг би здогадатися.
Але вона може сильно відрізнятися між продуктами.

Major.minor.point.build зазвичай. Основні та мінорні - це самопояснення, point - це випуск для кількох незначних помилок, а build - лише ідентифікатор збірки.

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

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

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

Парадигма основного виправлення release.minor release.bug досить поширена, я думаю.

У деяких контрактах на підтримку підприємств є $$$ (або порушення договірної відповідальності), пов'язане з тим, як визначено певний випуск. Наприклад, контракт може дати право замовнику на деяку кількість основних випусків за певний проміжок часу або обіцяє, що протягом періоду буде менше x кількості незначних випусків або що підтримка надалі буде доступна для такої кількості випуски. Звичайно, незалежно від того, скільки слів укладається в контракт, щоб пояснити, що таке головний реліз проти мінорного випуску, він завжди суб'єктивний, і завжди будуть сірі ділянки - це призводить до можливості того, що постачальник програмного забезпечення може грати в систему обіграти такі договірні положення.

Люди не завжди визнають тонку різницю між номерами версій на зразок 2.1, 2.0.1 або 2.10 - запитуйте у служби технічної підтримки скільки разів у них виникли проблеми з цим. Розробники орієнтовані на деталі та знайомі з ієрархічними структурами, тому для нас це сліпе місце.

Якщо це взагалі можливо, відкрийте своїм клієнтам простіший номер версії.

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

Випуск виправлення помилок потребує збереження сумісності бінарних даних, джерел та серіалізації.

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

Основні номери версій можуть містити всі три форми.

Я більше писав про обґрунтування тут .

Поєднання головного, мінорного, виправлення, складання, виправлення безпеки тощо.

Перші два є основними та незначними - решта залежатиме від проекту, компанії та інколи громади. В ОС на зразок FreeBSD у вас буде 1.9.0.1_кілька, щоб представляти патч безпеки.

Трохи залежить від мови, наприклад, Delphi і C # мають різні значення.

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

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

Трохи детальніше тут . "офіційно", в .net, 4 числа - "Major.Minor.Build.Revision", тоді як у Delphi є "Major.Minor.Release.Build". Я використовую "Major.Minor.ReallyMinor.SubversionRev" для своєї версії.

Зазвичай тоді номери у форматі version.major.minor.hotfix, а не окремих внутрішніх компонентів. Таким чином, v1.9.0.1 буде версією 1, основним випуском 9 (з v1), незначним випуском (з v1.9) 0, гарячим виправленням 1 (v1.9.0).

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

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

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

Остаточне число, як правило, є номером ревізії. Часто для цього використовується процес автоматичного збирання або коли ви робите одноразові викидні збірки для тестування.

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

Номер версії складної частини програмного забезпечення являє собою весь пакет і не залежить від номерів версій частин. Версія Gizmo 3.2.5 може містити версію Foo 1.2.0 та Bar версію 9.5.4.

Створюючи номери версій, використовуйте їх наступним чином:

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

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

3. Нумерація версій далі залежить від того, хто пише програмне забезпечення - Oracle використовує п'ять (!) Груп, тобто. версія Oracle - це щось на зразок 10.1.3.0.5. З третьої групи вниз вам слід вводити лише виправлення або незначні зміни функціональності.

ті, що відрізняються меншими, були б першими двома, для major.minor, після цього це може бути все - від складання, перегляду, випуску, до будь-яких спеціальних алгоритмів (як у деяких продуктах MS)

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

x.yz.bbbbb. Де: x: основна версія (основні нові функції) y: є другорядний номер версії (невеликі нові функції, невеликі вдосконалення без змін інтерфейсу користувача) z: це сервісний пакет (в основному такий же, як xy, але з деякими виправленнями помилок bbbb: - це номер збірки, який дійсно видно лише з поля "про коробку" з іншими деталями для підтримки клієнтів. bbbb - це безкоштовний формат, і кожен продукт може використовувати його власний.

Ось що ми використовуємо:

1. Перше число = Загальна епоха системи. Змінюється кожні пару років і, як правило, являє собою принципову зміну технології, особливостей клієнта або обох.
2. Другий номер = Перегляд схеми бази даних. Приріст цієї кількості вимагає міграції бази даних, і це суттєва зміна (або копії системи, і тому зміна структури бази даних вимагає ретельного процесу оновлення). Скидає на 0, якщо змінюється перше число.
3. Третє число = зміна лише програмного забезпечення. Зазвичай це може бути реалізовано клієнтом на основі клієнта, оскільки схема бази даних не змінюється. Скидає нуль, якщо друге число зміниться.
4. Номер версії субверсії. Ми автоматично заповнюємо це під час створення за допомогою інструменту TortoiseSVN. Ця кількість ніколи не скидається, а постійно збільшується. Використовуючи це, ми завжди можемо відтворити будь-яку версію.

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

версія: v1.9.0.1

де-

. v - абревіатура від версії. Це залежить від компанії до компанії, залежно від номенклатури, прийнятої в його організації. Він може замовчувати в такій організації, як 1.9.0.1

. 1 вказує на основну версію, буде оновлена ​​архітектурна модифікація в стеках додатків, інфраструктурі (платформи) або інтерфейсі відкритих мереж

. 9 інкаутів мінорні, будуть оновлені на такі дії, як додавання нових компонентів, таких як ui, api, база даних тощо; під конкретну архітектуру

. 0 вказує на функцію, буде оновлено будь-які вдосконалення для існуючих компонентів (ui, api, бази даних тощо)

. 1 вказує лічильник побудови для всіх основних фаз, другорядних та особливих фаз. Сюди також входять виправлення після випуску.