У многих начинающих разработчиков возникает вопрос: как назначать версию своей программы?
Поделюсь своим опытом.
Не буду вдаваться в теорию, тем более, что жестких рамок в данном вопросе нет. В своей практике я встречал много различных вариантов назначения версий программ.
Приведу несколько примеров написания версии:
Разберем каждое значение.
Ревизия (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]], так как оно больше подходит к моему стилю разработки.
(Visited 8 396 times, 1 visits today)
- , Метки: version, версия, программа, программирование
Источник: subreal-team.com
Нумерация версий ПО
Версия программного обеспечения нумеруется согласно схеме A.B.C.D, где:
- A — мажорная версия (major version) программного обеспечения;
- B — минорная версия (minor subversion, промежуточная версия) программного обеспечения;
- C — релиз (release) программного обеспечения;
- D — сборка (build) программного обеспечения. Также может использоваться простой номер программного обеспечения — A.B (например, при указании в эксплуатационных, рекламных и маркетинговых документах, на веб-сайте и т.д.).
Мажорная версия программного обеспечения
Изменение номера мажорной версии программного обеспечения происходит при глобальном изменении функциональности продукта (при введении нового порядка функциональности).
Первая мажорная версия продукта = 1. Мажорная версия продукта может быть = 0 в версии для внутреннего использования и тестирования в рамках компании, а также программы бета — тестирования нового продукта.
Изменения в сопровождении продукта
- При переходе на новую мажорную версию может быть: изменен весь спектр документации;
- изменены все маркетинговые материалы (включая листовки, краткие описания, информацию на сайте и проч.);
- изменен дизайн продуктов;
- введена новая позиция в прайс-листе.
Правила использования номера
При составлении ряда общих маркетинговых документов (листовок, перечня продукта, прайс-листов) допускается сокращение полного номера версии продукта до номера версии.
Переход на новую версию для пользователей — платный (за исключением пользователей, имеющих действующий контракт на получение новых мажорных версий программного обеспечения).
Вопрос перехода на новую мажорную версию решается руководством компании, отделом маркетинга и разработки.
Минорная версия программного обеспечения
Изменение номера минорной версии программного обеспечения происходит при:
- введении в продукт новой функциональности, ведущей к программной несовместимости с старой версией (несовместимость на уровне данных);
- изменений в схеме функционирования продукта (прежде всего — с точки зрения пользователя);
- значительных изменений (расширения, добавления новой) функциональности, появления в продукте новых конкурентных преимуществ.
Первая минорная версия = 0 (версия 1.0 – первый выход продукта на рынок). При выходе новой версии продукта нумерация минорной версии сбрасывается в нулевое значение.
Изменения в сопровождении продукта
Изменения, вошедшие в минорную версию, должны отражаться в документации по продукту, в том числе печатной. При выпуске коробочных продуктов возможна индикация номера минорной версии с помощью наклеек (к примеру «Версия 3.1»), или других средств, не меняя общий дизайн.
Минорная версия продукта может отражаться в части маркетинговых материалов, информации на сайте.
При выходе новой минорной версии должны информироваться партнеры компании, список изменений публикуется на сайте.
Правила использования номера
При составлении маркетинговых документов (расширенные таблицы, сравнения, листовки), всей бумажной документации по продукту и части электронной документации допускается сокращение полного номера версии продукта до номера минорной версии (3.1, он же — простой номер версии программного продукта). Переход на новую минорную версию для пользователей — бесплатный. Вопрос перехода на новую минорную версию решается отделом разработки (и техн. поддержки), при обязательном информировании отдела маркетинга.
Релиз программного обеспечения
Изменение номера релиза программного обеспечения происходит при каждом публичном выпуске обновления программного обеспечения, не обозначенном выше. Номерами релизов обозначаются выходы исправлений ошибок, не вносящие изменений в схему функционирования продукта и не влекущих несовместимость на уровне файлов данных (для обновления программного обеспечения не требуется специальных процедур конвертации/преобразования данных).
Нумерация релизов продукта начинается с 0 (версия 1.0.0 — первый выход продукта на рынок.).
При выходе новой промежуточной версии продукта нумерация релиза сбрасывается в нулевое значение.
При этом возможен выпуск релизов для предыдущих промежуточных версий продукта (по тем или иным техническим причинам, для поддержки пользователей).
Изменения в сопровождении продукта
Изменения, вошедшие в продукт, должны отображаться в документе «Замечания по версии» (Release Notes) и, возможно, в электронной документации (руководство пользователя).
Новый релиз размещается на сайте в разделе «Скачать» (Download), обновляется текущая версия дистрибутива. Отдел технической поддержки рекомендует пользователям совершить переход на данную версию. Возможна информационная рассылка пользователям по линии техподдержки и партнерам компании. Также, возможно создание установочных файлов, предназначенных специально для обновления программного обеспечения в пределах релиза.
Правила использования номера
В любых документах, передающихся пользователю и не описанных выше (описание файлов на сайте в разделе «Скачать» (Download), документ «Замечания по версии», информационные рассылки по линии техподдержки) полная версия продукта сокращается до номера релиза (3.1.5).
Переход на новый релиз для пользователей бесплатный. Вопрос создания нового релиза решается отделом разработки.
Номер сборки программного обеспечения
Изменение номера сборки программного обеспечения происходит при любой новой сборке продукта (компиляции программного обеспечения для внутренних целей).
Нумерация сборок продукта начинается с 1 (0.0.0.1 — первая сборка прототипа продукта). Номер сборки может сбрасываться при выходе новой версии продукта (по решению отдела разработки).
Изменения в сопровождении продукта
Изменений в сопровождении продукта не происходит.
Правила использования номера
Использовать номера сборки допускается только — во всей внутренней документации компании, системной информации по версиям файлов, окне «О программе», в частных случаях информационных рассылок по линии техподдержки.
Переход на новый номер сборки для пользователей возможен в случае проведения бета-тестирования, решения частных технических проблем совместно с отделом технической поддержки.
Вопрос создания нового билда решается отделом разработки совместно с отделом тестирования.
Совет по нумерации версий ПО найденный в интернете:
Весь процесс делю на чекпоинты. При достижении очередного чекпоинта увеличивается минорный номер. Проект имеет пометку dev Как только достигается заявленный функционал и начинается бета-тестирование — пометка dev убирается, увеличивается мажорный номер, минорный обнуляется и появляется пометка RC.
Номера RC увеличиваются в процессе тестирования (на практике крайне редко доходит до трех. Обычно RC1, гораздо реже добавляется RC2) Как только система проходит все тесты и достигает заявленного функционала — то релиз. Можно писать ТЗ на дальнейшее расширение функциональности и начинать все заново.
- VNS. Схема нумерации версий
- Нумерация версий в PEAR
Some rights reserver, 2013 — Sergey Poterianski
Источник: m0n0.ru
Нумерация версий программного обеспечения
Жизненный цикл любой программы — будь то десктопное или веб-приложение может быть продолжительным. Если проект активно развивается то в нем постоянно что-то меняется: добавляются новые функции или исправляются ошибки. Как правило, название проекта при этом никуда не девается, а меняется версия проекта.
Вариант 1. Нумерация целым числом
Обычно программы нумеруются целыми числами 1,2,3,4,5,6,7 и т.д. когда новая версия программы сложна, долго пишется и появляется только раз в год или несколько лет. После того, как такая программа будет протестирована, она помечается целым номером и выпускается для использования. Какие-либо мелкие изменения, добавляемые в процессе обслуживания программы, не учитываются в нумерации. Например, целым числом нумеруется Corel Draw (Corel Draw 10, Corel Draw 11)
Вариант 2. Десятичная дробь
Другой способ, который позволяет указать в версии программы серьезные и не большие изменения — это нумерация десятичной дробью. Например, как правило первая версия программы получает номер 1.0. При небольшом изменении увеличивается вторая цифра — 1.1. А при добавлении новой функции, изменяется вновь первая цифра, а вторая, следующая за ней, обнуляется — 2.0.
Вариант 3. Последовательные числа
Нумерация версий программы последовательными числами выглядит следующим образом.Версия программы состоит из трех или четырех чисел, разделенных точкой: например, 2.7.5.
- Первое число — старшая версия (major), изменяется при кардинальных изменениях программы
- Второе число — младшая версия (minor), изменяется при значительных изменениях функциональности
- Третье число (или буква) — стадия разработки
- Альфа версия — стадия тестирования приложения, число 0 или символ a
- Бета версия — стадия публичного тестирования приложения, число 1 или символ b
- RC (Release candidate) — релиз-кандидат — стадия-кандидат на то, чтобы стать стабильной версией, число 2 или символы rc
- RTM (Release To Manufacturing) — релиз — стабильная версия приложения, число 3 или символы rtm
- GA (General availability) — общедоступный релиз
Он может отсутствовать, и тогда вместо него ставится следующее число.
- Четвертое число — небольшие изменения (micro, maintenance), изменяется при любом, даже незначительной правке программы
Когда одно из чисел увеличивается, то все следующие за ним сбрасываются до нуля: 1.0.0, 1.0.1, 1.0.2, 1.1.0 и т.д. Часто, последний ноль может отбрасываться из версии, например: 1.0.0 = 1.0
Например, последовательные числа используют в Adobe Photoshop (Adobe Photoshop 7.0)
Вариант 4. Нумерация годом
Обычно, год используют в качестве нумерации для программных продуктов, которые долго разрабатываются и новые версии которых выходят не очень часто. Например, продукты того же Microsof, взять хотя бы их операционную систему или пакеты офисных утилит Word, Excel, PowerPoint и т.п.
Вариант 5. Нумерация текстом
Кроме чисел, в нумерации программы могут участвовать и различные буквы. Например, как это сделано в интегрированной среде разработки Delphi (Delphi XE)
Выбор, как именно нумеровать программу, выбирается по следующим причинам:
- в зависимости от использования системы контроля версии или иных инструментов разработки
- частота изменений в программе
- в маркетинговых целях, когда чтобы не отставать от конкурентов, разработчики проекта перескакивают на новый номер версии
Какой именно тип нумерации версий используете вы?
Источник: unetway.com