Нумерация версий программы

У многих начинающих разработчиков возникает вопрос: как назначать версию своей программы?

Поделюсь своим опытом.

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

Приведу несколько примеров написания версии:

major.minor[.build[.revision]]

major.minor[.patch[.build]]

year.month.day[.build]

Разберем каждое значение.

Ревизия (Revision)

Номер ревизии (revision) в системе управления версиями (Version Control System, VCS или Revision Control System). Благодаря ему, можно легко получить исходный код конкретной версии, выгрузив его из хранилища. Как правило, данное значение начинается с 1 с последующим увеличением соответственно номеру ревизии и никогда не обнуляется. В силу того, что значение важно только для разработки, в нумерации программы его часто опускают.

Билд (build)

Иными словами, номер сборки программы. После изменения в коде программы, как правило, проводят сборку программы, т.е. полную компиляцию всех файлов проекта.  Как правило, данное значение начинается с 1 с последующим увеличением соответственно номеру сборки. Обнуление сборки либо не проводят никогда, либо при смене мажорной (major) версии.  В силу того, что это значение важно только для разработки, в нумерации программы его часто опускают.

Патч или заплатка (patch)

Значение изначально устанавливается в 0 и увеличивается по мере внесения незначительных изменений в программу, например исправление какой-либо ошибки. Обнуляется при смене мажорной или минорной версий.

Минорная версия (minor)

Значение изначально устанавливается в 0 и увеличивается по мере внесения существенных изменений в программу, например, добавления нового функционала в программу. Значение также может повышаться при накоплении мелких изменений (патчей).  Обнуляется при смене мажорной версии.

Мажорная версия (major) 

Собственно говоря, это и есть версия программы. Значение мажорной версии устанавливается равной 1. Увеличивается данное значение с выходом новой версии,  когда происходят значительные переходы в функциональности, например, добавлены новые функции, существенно меняющие возможности программы, изменен интерфейс, переписаны основные алгоритмы и т.п. Значение также может повышаться при накоплении серьезных (минорных) изменений.

Для пред-релизных версий используют значение равное 0, получая номер вида 0.9.*.*

Год.Месяц.День (year.month.day)

Такое назначение версии указывает на дату выхода программы, что удобно для конечного пользователя. Исходя из такой нумерации пользователь может судить о том, как давно вышла конкретная версия программы, и не пора ли проверить обновление. К сожалению, подобная версионность не всегда удобна для разработчиков, особенно когда над проектом работает не один человек.

Кроме указанных позиций, разработчики часто используют буквенные обозначения в номере версии:

alpha — как правило, первая публичная тестовая версия, перед выходом финальной версии. Служит для обкатки и тестирования.

beta — вторая публичная тестовая версия, перед выходом финальной версии. Также служит для тестирования.

RC, RC2 — релиз-кандидат (Relise Candidate) версия, почти готовая к релизу. Служит для окончательной проверки.

final — окончательная (финальная) версия программы. Используется крайне редко, обычно просто опускается.

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

В своей практике я использую написание вида major.minor[.patch[.build]], так как оно больше подходит к моему стилю разработки.

One comment to this article

  1. SnowLeo

    on 20.10.2012 at 13:06 -

    У final есть еще псевдоним — relise. Используется иногда и он, но бывает что и тот и тот вариант используют разработчики в разных случаях.