Які способи нумерації версій існують
Назріло питання про версії товарів. Пошук в мережі і на хабрі до очевидних відповідей не привів :(, можливо через те, що не розумію(не знаю) що шукати. Тому вирішив звернутися до шановної спільноти. Сподіваюся відповіді будуть корисні багатьом розробникам-початківцям.
Як правильно (які варіанти) нумерації версій ПЗ? Власне цікавлять деякі правила (закони), за якими йде нумерація версій ПЗ. Наприклад:
Якщо версія продукту складається з X.Y.Z, то Z - збільшується при виправленні багів Y - при зміні, може додавання функціональності X - коли виходить повністю оновлений код або щось типу
Ось би знайти де почитати різні типи (види) нумерації версій та приклади їх застосування. Може хто поділився своїм досвідом, які плюси та підводні камені були при використанні?
Спасибі за допомогу!
P.S. Теги за якими можна знайти корисний матеріал на цю тему — вітаються.
Зазвичай Z збільшується при хотфіксі, Y - наступна версія з деяким функціоналом, X - несумісні зміни або багато функціонала. Але все залежить від домовленостей :) Наприклад OpenBSD використовує X.Y і збільшує на 0.1 кожні півроку, відповідно між версією 4.9 і 5.0 просто минуло півроку, а не якісь фікси/баги/фічі. Багато нумерують як Ubuntu - X.Y.Z де X - рік випуску, Y - місяць, Z - з'являється тільки якщо >0 і означає сек'юріті апдейт X.Y версії. Ну і є ті, хто нумерують просто датою 20121009.1
Застосовуйте той спосіб, який найбільше підходить під ваші завдання.
Не скажу, що гуру, але можливо і мій погляд на версування допоможе чимось.
Версування ПЗ допомагає:
1) Маркетингу 2) Саппорту 3) Розробнику 4) Тестувальнику
п.1. Маркетолог може сказати «Ув. користувач ми випустили нову мажорну версію, у цій версії продукту багато багфіксів і багато смачних фіч.». п.2. Спеціаліст саппорта може мати можливість відповідати більш предметно на проблеми, наприклад «По лиц.политике одна мажорна версія дійсна протягом ... місяців, Ваша версія застаріла. Вам варто зв'язатися з відділом продажів для Оновлення» або «Ми не можемо відтворити Вашу ситуацію, яка версія продукту у Вас стоїть?» п.3 Розробник побачивши завдання в баг-трекері може сказати: «Я чогось не зрозумію, для stable-гілки коміти є, баг виправлений. У якій саме версії це відтворюється? п.4. Тестувальник також, як і розробник, може стверджувати «Я протестував фікс баги на новій версії…, а також версії… проблема не відтворюється, баг пофіксований»
Версування це інструмент, що дозволяє уникнути багатьох непорозумінь при розмові фахівців різних професій: маркетолог, відділ продажу, сапорт, розробник, тестувальник.
Із цього випливають слід. питання: 1) Яка доля софту проданого покупцю? 2) Чи потрібно зберігати історію білдів та версій софту чи достатньо мати один stable-розлив? 3) Як Ви хочете повідомляти тех.спеціалістам про те, що Ваша програма змінилася координально і можливо вона не сумісна з форматами попередньо. версій або вона просто отримала дод. баг-фікси і кілька нових фіч? 4) Чи хочете ви говорити покупцям що Ви реально круто попрацювали і їм час би заплатити грошей Вам щоб Вашу роботу оцінити?
Як правило, бачачи зміну мажорної версії багато фахівців запитують: 1) Чи сумісна нова версія з колишніми форматами? 2) Чи змінився GUI і чи потрібно оновлювати інструкції щодо використання в корпоративній документації нашої компанії? 3) Требаможна проводити приймальне випробування?
І ряд. ін важливих питань
Також у рядок про версію іноді включається і ревізія із системи контролю версії, це допомагає розробникам не розкриваючи нічого про внутрішню структуру ПЗ.