Найкраща практика: Версія програмного забезпечення [закрито]

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

Але з чого я починаю версію? 0,0,0? або 0,0? І як тоді я збільшити цифри? основна зміна release.minor? і чи не повинно будь-яка прихильність до системи управління версіями бути іншою версією? або це лише для версій, які продуктивно використовуються?

Почати слід з версії 1, якщо ви не знаєте, що перша версія, яку ви "випускаєте", певним чином не є повною.

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

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

Тож якщо ви зробите значну зміну, перейдіть з версії 1.0.0.0 у версію 2.0.0.0 (ви змінили з WinForms на WPF, наприклад). Якщо ви зробите меншу зміну, перейдіть з 1.0.0.0 на 1.1.0.0 (ви додали підтримку файлів png). Якщо ви внесли незначні зміни, перейдіть з 1.0.0.0 до 1.0.1.0 (виправили деякі помилки).

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

Я б використовував x.y.zрізновид версій

x- основний реліз
y- незначний реліз
z- номер складання

Я в основному дотримуюся цієї схеми:

• починати з 0,1.0

• коли він готовий, я розгалужую код у вихідному репо, тег 0.1.0 і створюю гілку 0.1.0, голова / стовбур стає 0.2.0-знімок або щось подібне

• Я додаю нові функції лише до магістралі, але виправляє backport до гілки і з часом випускаю з неї 0.1.1, 0.1.2, ...

• Я оголошую версію 1.0.0, коли продукт вважається функцією завершеним і не має великих недоліків

• з цього моменту - кожен може вирішити, коли збільшити основну версію ...

Я використовую це правило для своїх додатків:

ксиз

Де:

• x = основний номер версії, 1- ~.
• y = номер функції, 0-9. Збільште це число, якщо зміна містить нові функції з виправленнями помилок або без них.
• z = номер виправлення, 0- ~. Збільште це число, якщо зміна містить лише виправлення помилок.

Приклад:

• Для нової програми номер версії починається з 1.0.0.
• Якщо нова версія містить лише виправлення помилок, збільште число виправлень, тому номер версії буде 1.0.1.
• Якщо нова версія містить нові функції з виправленнями помилок або без них, збільште номер функції та відновіть нуль виправлення до нуля, щоб номер версії становив 1.1.0. Якщо номер функції досягає 9, збільште номер основної версії та скиньте нуль функції та виправлення до нуля (2.0.0 тощо)

Ми використовуємо abcd де

• a - основний (збільшується при доставці клієнту)
• b - неповнолітній (збільшується при доставці клієнту)
• c - перегляд (збільшується на внутрішні випуски)
• d - нарощування (збільшується за допомогою круїз-контролю)

Ще один приклад A.B.Cпідходу - версія Eclipse Bundle . Пучки затемнення мають четвертий сегмент:

У Eclipse номери версій складаються з чотирьох (4) сегментів: 3 цілих числа та рядка відповідно названих major.minor.service.qualifier. Кожен сегмент фіксує різні наміри:

• основний сегмент вказує на поломку в API
• незначний сегмент вказує на "зовні видимі" зміни
• сервісний сегмент вказує на виправлення помилок та зміну потоку розвитку
• сегмент класифікатора вказує на конкретну збірку

Існує також дата версій схеми , наприклад: YYYY.MM, YY.MM,YYYYMMDD

Це досить інформативно, оскільки перший погляд створює враження про дату випуску. Але я віддаю перевагу схемі xyz, тому що я завжди хочу знати точний момент продукту в його життєвому циклі (Major.minor.release)

Основна відповідь - "Це залежить".

Яка мета у версії? Багато людей використовують version.revision.build і лише рекламують version.revision у світі, оскільки це версія для випуску, а не версія для розробників. Якщо ви користуєтесь "версією" для реєстрації, ви швидко виявите, що номери ваших версій стали великими.

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

І все-таки наприкінці дня це залежить від вас і це має мати сенс для вас.

Як каже Махеш: я б використовував версію xyz

x - основний випуск y - мінорний випуск z - номер збірки

ви можете додати дату, можливо замість z.

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

Ви знаєте, що завжди можете перевірити, що роблять інші. Програмне забезпечення з відкритим кодом, як правило, дозволяє отримати доступ до своїх сховищ. Наприклад, ви можете вказати свій браузер SVN на http://svn.doctrine-project.org і подивитися на систему версій, використовувану реальним проектом.

Номери версій, теги, це все є.

Ми дотримуємось abc-підходу, як:

"a", якщо в застосуванні сталися якісь значні зміни. Як і ми оновимо додаток .NET 1.1 до .NET 3.5

нарахування 'b', якщо є якісь незначні зміни, як-от будь-яка нова CR або Enhancement.

increament 'c', якщо в коді є деякі виправлення дефектів.

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

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

Я думаю, що найбільш прийнятний зразок abc або abcd, особливо якщо у вас суміш QA / Compliance. У мене було стільки недоліків навколо дати, що є регулярною частиною версій, що я віддав її для мейнстріму.

Я не відстежую складання, тому люблю використовувати шаблон abc, якщо не буде виправлено виправлення. Коли мені потрібно застосувати виправлення, я застосовую параметр d як дату з часом. Я прийняв параметр часу як d, оскільки завжди є потенціал декількох в день, коли речі справді підірваються у виробництві. Я застосовую d-сегмент (YYYYMMDDHHNN) лише тоді, коли я розходяться для виправлення виробництва.

Я особисто не був би проти програмної схеми va.b revc, де c - YYYYMMDDHHMM або YYYYMMDD.

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