Что означают цифры в версии программ
Номера версий продукта
Как известно, каждая выходящая в свет версия программы имеет свой собственный номер. Казалось бы, эта тема предельно проста и не требует дополнительных пояснений, но на некоторых аспектах вопроса о номерах версий мне все-таки хотелось бы остановиться поподробнее.
Среди разработчиков программных продуктов (не только shareware) уже очень долго существует соглашение о порядке нумерации версий программ. Вы наверняка слышали о нем:
Изменение номера основной версии происходит при внесении в программу серьезных изменений, например, при смене интерфейса, включении новых функций, значительно повышающих возможности продукта. Если в программу были внесены небольшие изменения, то меняется первая цифра после точки; если сделанные изменения совсем уж незначительны, то меняется вторая цифра после точки.
Некоторые из читателей, возможно, подумают: «Как это все запутанно». И будут совершенно правы! Для многих пользователей даже такие простые номера версий, как 3.1 или 6.0, сложны для запоминания, не говоря уже о номерах типа 5.00.2614.3500.
Действительно, можете ли вы вспомнить полный номер версии браузера Internet Explorer, установленного у вас?
Не менее интересен и вопрос политики изменения номеров версий по мере развития shareware-продукта.
Еще со времен появления первых программ для персональных компьютеров существует пользовательский стереотип, который очень распространен и сегодня: только с версии 2.0 программа становится достойна внимания. Такое мнение выработалось в результате разочарований, которые испытывали пользователи, попробовав многочисленные программы, стремительно заполнившие рынок программного обеспечения, в том числе и shareware.
«Боязнь» разработчиков программ к существенному изменению номера версии обусловлена в основном тем, что они опасаются негативной реакции пользователей. На мой взгляд, это оправдано только в одном случае: автор предоставляет зарегистрированным пользователям бесплатно не все последующие версии, а только лишь minor updates, т. е. те обновления, номера версий которых изменяются в пределах цифр после точки. Например, если пользователь приобрел версию 1.2, то версии 1.3, 1.45, 1.6 и т. п. он получит бесплатно, а за версию 2.0 должен будет заплатить еще какую-то дополнительную сумму. По этой схеме распространяется, в частности, текстовый редактор UltraEdit (http://www.utlraedit.com). В этом случае при выходе версий 2.0, 3.0 и т. п. автор программы должен следить, чтобы эти версии по своим возможностям действительно сильно отличались от предыдущих, иначе пользователи будут очень недовольны тем, что их вынуждают платить за незначительные исправления.
Если же зарегистрированные пользователи получают все последующие обновления бесплатно, то не нужно опасаться смены номера версии. Конечно, выпускать версию 2.0, внеся в версию 1.0 лишь небольшие изменения, не стоит. Однако и тянуть с выходом версии 2.0 (или еще хуже, 1.0), выпуская один minor update за другим, тоже не нужно. Лично я практически отказался от использования в номере версии второй цифры после точки, чтобы сделать нумерацию версий простой для запоминания пользователями, а заодно увеличить скорость перехода на более солидные номера версий.
Среди известных программных продуктов много примеров довольно смелого обращения с номерами версий. Например, Dbase II появилась «с нуля»:
Нумерация версий программного обеспечения
Вариант 1. Нумерация целым числом
Обычно программы нумеруются целыми числами 1,2,3,4,5,6,7 и т.д. когда новая версия программы сложна, долго пишется и появляется только раз в год или несколько лет. После того, как такая программа будет протестирована, она помечается целым номером и выпускается для использования. Какие-либо мелкие изменения, добавляемые в процессе обслуживания программы, не учитываются в нумерации. Например, целым числом нумеруется Corel Draw (Corel Draw 10, Corel Draw 11)
Вариант 2. Десятичная дробь
Вариант 3. Последовательные числа
Нумерация версий программы последовательными числами выглядит следующим образом.Версия программы состоит из трех или четырех чисел, разделенных точкой: например, 2.7.5.
Он может отсутствовать, и тогда вместо него ставится следующее число.
Когда одно из чисел увеличивается, то все следующие за ним сбрасываются до нуля: 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)
Выбор, как именно нумеровать программу, выбирается по следующим причинам:
Какой именно тип нумерации версий используете вы?
Автор
Программист с образованием в области IT и опытом разработки на разных языках. Автор статей по программированию. Общий опыт работы в сфере IT и интернета более 5 лет.
Нумерация версий ПО
Версия программного обеспечения нумеруется согласно схеме A.B.C.D, где:
Мажорная версия программного обеспечения
Изменение номера мажорной версии программного обеспечения происходит при глобальном изменении функциональности продукта (при введении нового порядка функциональности).
Изменения в сопровождении продукта
Правила использования номера
При составлении ряда общих маркетинговых документов (листовок, перечня продукта, прайс-листов) допускается сокращение полного номера версии продукта до номера версии.
Переход на новую версию для пользователей — платный (за исключением пользователей, имеющих действующий контракт на получение новых мажорных версий программного обеспечения).
Вопрос перехода на новую мажорную версию решается руководством компании, отделом маркетинга и разработки.
Минорная версия программного обеспечения
Изменение номера минорной версии программного обеспечения происходит при:
Первая минорная версия = 0 (версия 1.0 – первый выход продукта на рынок). При выходе новой версии продукта нумерация минорной версии сбрасывается в нулевое значение.
Изменения в сопровождении продукта
Изменения, вошедшие в минорную версию, должны отражаться в документации по продукту, в том числе печатной. При выпуске коробочных продуктов возможна индикация номера минорной версии с помощью наклеек (к примеру «Версия 3.1»), или других средств, не меняя общий дизайн.
Минорная версия продукта может отражаться в части маркетинговых материалов, информации на сайте.
При выходе новой минорной версии должны информироваться партнеры компании, список изменений публикуется на сайте.
Правила использования номера
Релиз программного обеспечения
Изменение номера релиза программного обеспечения происходит при каждом публичном выпуске обновления программного обеспечения, не обозначенном выше. Номерами релизов обозначаются выходы исправлений ошибок, не вносящие изменений в схему функционирования продукта и не влекущих несовместимость на уровне файлов данных (для обновления программного обеспечения не требуется специальных процедур конвертации/преобразования данных).
Нумерация релизов продукта начинается с 0 (версия 1.0.0 — первый выход продукта на рынок.).
При выходе новой промежуточной версии продукта нумерация релиза сбрасывается в нулевое значение.
При этом возможен выпуск релизов для предыдущих промежуточных версий продукта (по тем или иным техническим причинам, для поддержки пользователей).
Изменения в сопровождении продукта
Изменения, вошедшие в продукт, должны отображаться в документе «Замечания по версии» (Release Notes) и, возможно, в электронной документации (руководство пользователя).
Новый релиз размещается на сайте в разделе «Скачать» (Download), обновляется текущая версия дистрибутива. Отдел технической поддержки рекомендует пользователям совершить переход на данную версию. Возможна информационная рассылка пользователям по линии техподдержки и партнерам компании. Также, возможно создание установочных файлов, предназначенных специально для обновления программного обеспечения в пределах релиза.
Правила использования номера
В любых документах, передающихся пользователю и не описанных выше (описание файлов на сайте в разделе «Скачать» (Download), документ «Замечания по версии», информационные рассылки по линии техподдержки) полная версия продукта сокращается до номера релиза (3.1.5).
Переход на новый релиз для пользователей бесплатный. Вопрос создания нового релиза решается отделом разработки.
Номер сборки программного обеспечения
Изменение номера сборки программного обеспечения происходит при любой новой сборке продукта (компиляции программного обеспечения для внутренних целей).
Нумерация сборок продукта начинается с 1 (0.0.0.1 — первая сборка прототипа продукта). Номер сборки может сбрасываться при выходе новой версии продукта (по решению отдела разработки).
Изменения в сопровождении продукта
Изменений в сопровождении продукта не происходит.
Правила использования номера
Переход на новый номер сборки для пользователей возможен в случае проведения бета-тестирования, решения частных технических проблем совместно с отделом технической поддержки.
Вопрос создания нового билда решается отделом разработки совместно с отделом тестирования.
Статья взята отсюда: http://www.free-lance.ru/users/shupruta/upload/fileqZud2j.pdf (к сожалению ссылка больше не работает)
Совет по нумерации версий ПО найденный в интернете:
Some rights reserver, 2013 — Sergey Poterianski
Нумерация версий программы
У многих начинающих разработчиков возникает вопрос: как назначать версию своей программы?
Поделюсь своим опытом.
Не буду вдаваться в теорию, тем более, что жестких рамок в данном вопросе нет. В своей практике я встречал много различных вариантов назначения версий программ.
Приведу несколько примеров написания версии:
Разберем каждое значение.
Ревизия (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 — окончательная (финальная) версия программы. Используется крайне редко, обычно просто опускается.
Какую схему наименования версий использовать решать прежде всего разработчикам, главное, чтобы нумерация была удобна в разработке и понятна конечному пользователю. И это один из тех вопросов, о которых необходимо договариваться в самом начале разработки любого проекта.
Какие существуют основные способы версионирования программ?
Почти у каждой программы есть номер её версии, например: ‘1.23’, ‘2.3568’, ‘3.89_32’, ‘Ubuntu 12.04’, ‘Linux 3.16.0’, ‘perl v5.20.2’ и т.п.
Отсюда вопрос: какие существуют распространённые способы задания номера версии программ и по какому принципу они задаются (что означают конкретные цифры в названии версии)?
3 ответа 3
Самая распространённая схема версионирования:
Может быть добавлено ещё одно число, обозначающее номер сборки (build). Например: 2.0.63.4
Номер версии состоит из следующих компонент: мажорный* (старший) номер версии, минорный (младший), номер билда**, и номер ревизии, из которых используется две, три или четыре. Мажорный и минорный номера обязательны, ревизия или ревизия и номер билда могут быть опущены. Значения свойств — неотрицательные целые числа. Номер версии записывается в виде
(части в квадратных скобках необязательны).
Компоненты должны означать следеующее:
Мажорный номер: Сборки (то есть, файлы библиотек) с одним и тем же именем, но разными мажорными версиями не взаимозаменяемы. Старшая версия может означать полное переписывание кода, без сохранения обратной совместимости.
Минорный номер: Если имя и мажорный номер версии двух сборок одинаковы, но минорные номера отличаются, это означает существенные изменения с сохранением обратной совместимости. Более высокая минорная версия может означать новый релиз того же продукта или полностью обратно совместимую новую версию того же продукта.
Номер билда: Одинаковый номер билда означает рекомпиляцию того же самого исходного текста. Различные номера билдов нужны, если повторная компиляция производится для другого процессора, платформы, опций оптимизации, или другим компилятором.
Ревизия: Сборки с одинаковым именем, мажорной и минорной версией, но разными ревизиями, должны быть полностью взаимозаменяемыми. Более высокий номер ревизии может быть использован для выпуска версии, закрывающей критическую ошибку безопасности выпущенной раньше версии.
Последовательные выпуски версий сборки, отличающиеся лишь номером билда и/или ревизией, считаются хотфиксами (заменами, закрывающими проблемы) предыдущей версии.
*Термины «мажорный» и «минорный» — калька от «major» и «minor», но они, кажется, устоялись.