Як номери ранньої версії працюють на нові продукти?

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

Моє дослідження показало ці пов'язані результати

• Яку "угоду про назву версій" ви використовуєте?
• Як ви версите свої файли (номери версій)
• Запропонований проект, звідки починаються номери моїх версій?

але жодна з них не стосується нумерації альфа-версій, бета-версій, кандидатів на випуск тощо. Які умови для номерів версій нижче 1,0? Я знаю, що вони можуть тривати деякий час; наприклад, PuTTY існує вже щонайменше десятиліття і досі працює лише у версії бета-версії 0.60.

Це дійсно залежить від проекту; деякі проекти навіть не випускають версію 1.0.

Розробники MAME не мають наміру випускати версію 1.0 своєї емуляторної програми. Аргумент полягає в тому, що він ніколи не буде по-справжньому «закінченим», оскільки завжди буде більше аркадних ігор. Версія 0.99 просто супроводжувалась версія 0.100 (незначна версія 100> 99). Аналогічно Xfire 1.99 супроводжував 1.100. Після 6 років розвитку, eMule ще не досягла версії 0,50. ^{Версія програмного забезпечення у Вікіпедії}

Один з популярних методів нумерації версій (який я почав використовувати) - це семантична версія .

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

Деякі цитати, щоб дати вам більше ідей щодо того, як це працює та / або відповісти на деякі ваші запитання:

Як дізнатись, коли випустити 1.0.0?

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

Це не перешкоджає швидкому розвитку та швидкій ітерації?

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

Якщо навіть найдрібніші зміни несумісних змін у загальнодоступному API потребують значного нарікання версій, чи не дуже швидко я закінчуватиму версію 42.0.0?

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

Також є правила щодо того, як вказати випуски "альфа", "бета" тощо. Перегляньте деталі на веб-сайті http://semver.org/ .

[Редагувати] Ще одна цікава схема нумерації версій - та, яку використовує MongoDB :

MongoDB використовує версії з непарними номерами для версій розробки.

У версії MongoDB є 3 номери: ABC

• A - основна версія. Це рідко змінюватиметься і означатиме дуже великі зміни
• B - номер випуску. Це стосуватиметься багатьох змін, включаючи функції та речі, які можуть порушити сумісність. Навіть Bs будуть стабільними гілками, а непарні Bs - розвитком.
• C - номер редакції, який буде використовуватися для помилок та проблем безпеки.

Наприклад:

• 1.0.0: перший GA-реліз
• 1.0.x: виправлення помилок до 1.0.x - дуже рекомендується оновити, дуже мало ризику
• 1.1.x: випуск розробки. це буде включати нові функції, які не повністю закінчені та працюють незавершеними. Деякі речі можуть відрізнятися від 1,0
• 1.2.x: другий випуск GA. це стане вершиною випуску 1.1.x.

Я не думаю, що існує "стандарт" як такий.

Існує конвенція щодо випуску кандидатів, яка зазвичай є "[версія] RC 1" тощо, залежно від того, скільки версій, на вашу думку, ви можете випустити.

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

Я б використовував "Альфа" та "Бета", як Release Candidate - для обмежених за часом версій, щоб вказати, що ви вважаєте, що готові випустити повну версію.

Сторінка Вікіпедії на версії програмного забезпечення . Для спільного використання версій до 1.0, конвенція, що використовується Apple та іншими, працює добре: major.minor.maintSrev, де S є етапом індикатора для попередніх версій: d = розробка, a = альфа, b = бета, rc = кандидат на випуск. Отже, ваша перша внутрішня версія може бути 1.0.0d1.

Для повністю внутрішніх доопрацювань часова мітка є достатньою.

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

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

Випуск 1.0 ---> 2.0 (Основна нова / покращена функція додана до продукту)

Випуск 1.0 ---> 1.1 (До продукту додана нова / покращена функція середнього рівня)

Випуск 1.0 ---> 1.001 (Виправлення)

Віха версії 1.0 є дуже важливою для досвідчених користувачів комп'ютерів, оскільки передбачає, що програма виконана і працює так, як очікувалося. Що-небудь у версії "0.що" означає, що програмісти самі думають, що програма ще не зроблена .

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