Какие способы нумерации версий существуют?

Question

[Dmitry T.]

Привет всем.

Назрел вопрос про версии продуктов. Поиск в сети и на хабре к очевидным ответам не привел :(, возможно из-за того, что не понимаю(не знаю) что искать. Поэтому решил обратиться к уважаемому сообществу. Надеюсь ответы будут полезны многим начинающим разработчикам.

Как правильно(какие есть варианты) нумерации версий ПО? Собственно интересуют некие правила(законы) по которым идет нумерация версий ПО. Например:

Если версия продукта состоит из X.Y.Z, то
Z — увеличивается при исправлении багов
Y — при изменении, может добавлении функциональности
X — когда выходит полностью обновленный код или что-то типа того

Вот бы найти где почитать разные типы(виды) нумерации версий и примеры их применения. Может кто поделился своим опытом, какие плюсы и подводные камни были при использовании?

Спасибо за помощь!

P.S. Теги по которым можно найти полезный материал по этой теме — приветствуются.

Answer 1

[DmZ]

Почитайте про семантическое версионирование SemVer как один из подходов.
Также интересно посмотреть как к версиям относятся различные пакетные менеджеры, например RPM: Naming Guidelines

Comments

[DmZ]

Обычно Z увеличивается при хотфиксе, Y — следующая версия с неким функционалом, X — обратно не совместимые изменения или много функционала.
Но, все зависит от договоренностей :) Например OpenBSD использует X.Y и увеличивает на 0.1 каждые полгода, соотвественно между версией 4.9 и 5.0 просто прошло полгода, а не какие-то фиксы/баги/фичи.
Многие нумеруют как Ubuntu — X.Y.Z где X — год выпуска, Y — месяц, Z — появляется только если >0 и означает секьюрити апдейт X.Y версии.
Ну и есть те кто нумеруют просто датой 20121009.1

Применяйте тот способ, который больше подходит под ваши задачи.

[Dmitry T.]

Спасибо, появилось немного пищи для размышлений.
В том то и дело, чтобы применить способ которые подходит, необходимо представлять какие способы есть :)

Answer 2

[Станислав]

А как же
habrahabr.ru/post/118756/
en.wikipedia.org/wiki/Software_versioning

Comments

[Dmitry T.]

спасибо большое!
буду изучать.

Answer 3

[KirAmp]

На ум приходит следующее:
версия.билд.дата (как у ms office)
версия.подверсия.билд (как у ms windows)

Comments

[Dmitry T.]

Может подскажите, а по какому принципу изменяется версия и подверсия? Возможно у вас есть своя интерпретация как надо, поделитесь пожалуйста.
Например, что делать с проектами которые разрабатываются с помощью скриптовых языков, у которых билдов как таковых нет?

[KirAmp]

Ну тогда оставить версию и подверсию.
Для скриптовых программок думаю подойдет вот такая система:
версия.подверсия.исправление_ошибок
Где версия — это версия принципиально переделанный функционал с множеством исправлений и доработок, видимых юзеру.
подверсия — это любой выкат на продакшен нового функционала или критических исправлений
исправление_ошибок — это незначительные исправления, почти не влияющие на работе пользователя с программой

[Dmitry T.]

спасибо, будем пробовать :)

Answer 4

[Дмитрий]

Не скажу что гуру, но возможно и мой взгляд на версирование поможет чем-то.

Версирование ПО помогает:

1) Маркетингу
2) Саппорту
3) Разработчику
4) Тестировщику

п.1. Маркетолог может сказать «Ув. пользователь мы выпустили новую мажорную версию, в этой версии продукта много багфиксов и много вкусных фич.».
п.2. Специалист саппорта может иметь возможность отвечать более предметно на проблемы, к примеру «По лиц.политике одна мажорная версия действительна в течении… месяцев, Ваша версия устарела. Вам стоит связаться с отделом продаж для Обновления» или «Мы не можем воспроизвести Вашу ситуацию какая версия продукта у Вас стоит?»
п.3 Разработчик увидев задачу в баг-трекере может сказать «Я чего-то не пойму, для stable-ветки комиты есть, баг исправлен. В какой конкретно версии это воспроизводится?»
п.4. Тестировщик также как и разработчик может утверждать «Я протестировал фикс баги на новой версии…, а также версии… проблема не воспроизводится, баг пофикшен»

Версирование это инструмент позволяющий избежать многих недоразумений при разговоре специалистов разных профессий: маркетолог, отдел продаж, саппорт, разработчик, тестировщик.

Из этого вытекают след. вопросы:
1) Какова судьба софта проданного покупателю?
2) Нужно ли хранить историю билдов и версий софта или достаточно иметь один stable-разлив?
3) Как Вы хотите сообщать тех.специалистам о том что Ваша программа изменилась координально и возможно она не совместима с форматами пред. версий или же она просто получила доп. баг-фиксы и несколько новых фич?
4) Хотите ли вы говорить покупателям что Вы реально круто поработали и им пора бы заплатить денег Вам чтобы Вашу работу оценить?

Как правило, видя изменение мажорной версии многие спецы задаются вопросами:
1) Совместима ли новая версия с прежними форматами?
2) Изменился ли GUI и нужно ли обновлять инструкции использования в корпоративной документации нашей компании?
3) Надо ли проводить приемочное испытание?

И ряд. др. важных вопросов

Также в строку о версии иногда включается и ревизия из системы контроля версии, это сильно помогает разработчикам не раскрывая ничего о внутренней структуре ПО.

Comments

[Dmitry T.]

спасибо за такой развернутый комментарий

Answer 5

[anitspam]

немного оффтопа из недавнего обновления «нетбинса» :)
Common Scripting Language API (new) [2.28.1.2.1.1.6 -> 2.28.2.2.1.1.6]