Понимание нумерации версий

В этой статье я хочу показать, как правильно нумеровать версии программ. Одна из самых распространенных нумераций - это нумерация в три уровня. По крайней мере я считаю ее достаточно "подробной", касательно внесения изменений в программу.
Итак, состав версионности. Это последовательность цифр, разделенных на уровни, например: 1.3.12 . Маска нумерации следующая: <major>.<minor>.<build>  . Этот способ нумерации используется в Windows API. Существует тонкость - при изменении одного из уровней, все последующие значения уровней обнуляются. Например, цепочка версий: 1.0.1 -> 1.0.2 -> 1.1.0 -> 2.0.0

Значение уровней

<build> - Значение этого уровня обычно меняется при исправлении каких-либо ошибок. Это значит, что для пользователя ничего не поменялось, кроме как были исправлены ошибки.
<minor> - Минорный уровень меняется, когда в программу добавляют различные плюшки, например новый функционал или элемент интерфейса. Важно то, что программа как работала так и работает, внесенные изменения ничего не сломали.
<major> - Это самый верхний уровень. Он меняется только тогда, когда программа переписывается заново или меняются функции, которые (если менять только их) сломают целостность программы. Например, функция запуска архивации стала принимать дополнительный обязательный параметр. В этом случае, предыдущий интерфейс, который работал с этой функцией, не сможет дать ей этот параметр, что приведет к ошибке. Естественно, в этом случае делаются глобальные изменения.

Версия 1.0

Коммерческие программы начинают свою нумерацию с версии 1.0. Да, такие версии очень сырые и, скорее всего, через месяц выйдет версия 1.1, еще через месяц 1.2, а через полгода или год выйдет версия 2.0. Может это и верный путь, но на мой взгляд правильно начинать с версии 0.1 и постепенно подиматься до 1.0 - версии, готовой к работе с обычными потльзователями. Это значит, что все мелкие ошибки исправлены и отлажена работа обычного пользователя. Да, никто не застрахован от того, что бы поймать какую нибудь ошибку, но это не повод расстраиваться и отказываться от программного продукта. Скорее всего на этот момент доблестная команда разработчиков уже трудится над ее устранением. В любом случае, если Вы первый, кто поймал такую ошибку, стоит подробно описать свои действия, которые ее вызвали и отправить на службу поддержки программы.

Заключение

Не нужно бояться "сырых" версий. Если программа достойна внимания, то и ошибки будут устраняться быстро. А Вы - обычные пользователи - самые первые помощники в улучшении качества программных продуктов. От лица всех разработчиков говорю вам СПАСИБО ЗА ВАШ ТРУД!