Какие существуют основные способы версионирования программ?
Почти у каждой программы есть номер её версии, например: ‘1.23’, ‘2.3568’, ‘3.89_32’, ‘Ubuntu 12.04’, ‘Linux 3.16.0’, ‘perl v5.20.2’ и т.п. Отсюда вопрос: какие существуют распространённые способы задания номера версии программ и по какому принципу они задаются (что означают конкретные цифры в названии версии)?
Отслеживать
50.4k 80 80 золотых знаков 256 256 серебряных знаков 492 492 бронзовых знака
задан 9 мая 2016 в 15:44
5,890 3 3 золотых знака 21 21 серебряный знак 42 42 бронзовых знака
9 мая 2016 в 15:55
9 мая 2016 в 19:16
3 ответа 3
Сортировка: Сброс на вариант по умолчанию
Самая распространённая схема версионирования:
major.minor.maintenance
major — крупные изменения, либо изменения несовместимые с предыдущей версией;
minor — добавление функционала без нарушения совместимости;
maintenance — исправления.
Может быть добавлено ещё одно число, обозначающее номер сборки (build). Например: 2.0.63.4
Павел Прилучный – Как Живет Главный Мажор России
Отслеживать
ответ дан 9 мая 2016 в 15:53
Pyramidhead Pyramidhead
2,178 11 11 серебряных знаков 17 17 бронзовых знаков
Бывает ещё третьим числом номер сборки.
9 мая 2016 в 15:54
9 мая 2016 в 15:55
Например, в .NET стандартно используется класс Version , содержащий свойства Major , Minor , Build и Revision . Переведу кусок официальной документации:
Номер версии состоит из следующих компонент: мажорный* (старший) номер версии, минорный (младший), номер билда**, и номер ревизии, из которых используется две, три или четыре. Мажорный и минорный номера обязательны, ревизия или ревизия и номер билда могут быть опущены. Значения свойств — неотрицательные целые числа. Номер версии записывается в виде
major.minor[.build[.revision]]
- Мажорный номер: Сборки (то есть, файлы библиотек) с одним и тем же именем, но разными мажорными версиями не взаимозаменяемы. Старшая версия может означать полное переписывание кода, без сохранения обратной совместимости.
- Минорный номер: Если имя и мажорный номер версии двух сборок одинаковы, но минорные номера отличаются, это означает существенные изменения с сохранением обратной совместимости. Более высокая минорная версия может означать новый релиз того же продукта или полностью обратно совместимую новую версию того же продукта.
- Номер билда: Одинаковый номер билда означает рекомпиляцию того же самого исходного текста. Различные номера билдов нужны, если повторная компиляция производится для другого процессора, платформы, опций оптимизации, или другим компилятором.
- Ревизия: Сборки с одинаковым именем, мажорной и минорной версией, но разными ревизиями, должны быть полностью взаимозаменяемыми. Более высокий номер ревизии может быть использован для выпуска версии, закрывающей критическую ошибку безопасности выпущенной раньше версии.
*Термины «мажорный» и «минорный» — калька от «major» и «minor», но они, кажется, устоялись.
Павел Прилучный — впервые про развод, депрессию, вторую свадьбу и новый «Мажор»
**Слово «сборка» в мире .NET имеет устоявшееся значение.
Источник: ru.stackoverflow.com
Мажорная версия программы что это
Семантическое Версионирование (англ. Semantic Versioning), также известный как semver (семвер) — спецификация о том, как присваивать версии релизам программного обеспечения.
Основная идея в том, что версия должна состоять из трёх обязательных номерных версий: .. .
- Мажорная версия — та версия, в которой можно полностью менять поведение, API, удалять старый код и т.д. Изменение данной версии, как правило, требует очень тщательного изучения различий между той, что используется на данный момент проектом. Они могут быть совершенно несовместимы. То, насколько мягким будет переход, зависит только от разработчиков.
- Минорная версия — предназначена для добавления нового функционала или внесения больших изменений, которые соблюдают обратную совместимость (BC).
- Патч версия — используется для внесения мелких изменений, в основном, исправлений ошибок или легкий рефакторинг кода.
Семантическое версионирование также поддерживает и дополнительные части, идущие после патч версии. Например, там могут быть метки о том что это предварительный релиз или какой-то конкретный билд. Например: 1.2.3-beta.1 , 1.2.3+abc123 или 1.2.3-beta.1+abc123 — обратите внимание что билд отделяется + (плюс), а наименование предварительного релиза — (дефис). Данные дополнительные указатели говорят о том, что релиз не стабильный, и в нём могут как всё поменять, так и вовсе удалить, либо добавить совершенной новый функционал в будущем.
Зная как устроено данное именование, можно легко управлять зависимостями, например в Composer, который также использует семантическое версионирование. Это позволяет делать более точные ограничения, например, разрешить обновлять пакет только в пределах патч релиза, и вы будете уверены, что никакой новый API не попадёт на проект, а будут поступать только исправления ошибок.
¶Семантическое версионирование в Drupal
Drupal всегда использовал некое подобие семантического версионирования -. . То есть, ядро и модули были лишены патч версии, и все обновления поступали в минорной версии. Это могло вызывать некоторые сложности и не всегда понятно, чего ожидать от релиза, зная лишь новую версию.
Начиная с Drupal 8 в ядре адаптировали семантическое версионирование. Таким образом, начиная с данной мажорной версии друпала, именование ведётся в соответствии с данной спецификацией.
При нумерации версий ядра используются только ..- . Единственное что может броситься в глаза, это то, что пред-релизное именование у нас ведётся без точки: alpha1 , beta2 , rc3 , вместо того как это приводится в примерах alpha.1 , beta.2 , rc.3 . Тем не менее это соответствует спецификации, но не забывайте о данной особенности когда будете именовать свои релизы!
¶Смотрите также
¶Ссылки
- Семантическое Версионирование, semver.org.
- Semantic Versioning (англ.), semver.org.
Источник: druki.ru
Нумерация версий ПО
Версия программного обеспечения нумеруется согласно схеме 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
GIT-ветвление и попытка не запутаться
Наша компания занимается разработкой ПО для госсектора и постоянно сертифицирует свои программы для обработки гос. тайны. А это накладывает определенные ограничения и самое главное из них: мы должны предоставить все исходные коды нашего проекта и если попросят суметь объяснить, что делает каждая строчка.
Проблема в том, что если используешь готовые компоненты, то их исходники тоже нужно предоставлять и уметь все про них рассказать. Поэтому мы решили сделать свой фреймворк, ведь про него мы будем знать все. Фреймворк мы сделали и назвали его «Platform». Он продолжает развиваться и все свои проекты мы делаем на нем.
Проблема заключается в том что, после выпуска продукта и его сдачи мы вынуждены его замораживать и не можем в него вносить больших изменений — только исправлять баги, а большинство багов обнаруживается как раз в самом фреймворке и в результате мы вынуждены иметь версии фреймворка для каждого сданного проекта (ну или для группы одновременно выпущенных продуктов). В итоге, нам пришлось придумать свой набор правил и схему ветвления в GIT для разработки Platform. Схема приведена ниже вместе с примером работы по ней:
Общие правила ветвления проектов:
1. Введены следующие понятия:
a. Мажорная версия программы – версия программы в рамках определенной концепции, меняется при значительных изменениях концепции, обозначается v-m, где m – номер мажорной версии;
b. Минорная версия программы – подверсия в рамках одной концепции, меняется при добавлении нового функционала или незначительной переделке существующего, обозначается v-m-n, где m – номер мажорной версии, n – номер минорной версии;
c. Релиз программы – вариант минорной версии, номер релиза меняется при незначительных изменениях и/или исправлении багов в соответствующей минорной версии программы, обозначается r-m-n-p, где m – номер мажорной версии, n – номер минорной версии, p – номер патча;
2. Разработка нового функционала ведётся в ветке master. Ветка master защищённая, для помещения изменений в неё разработчиками выполняется merge-request. Решение по принятию merge-request принимает технолог на основании просмотра исходного кода вносимых изменений (code review).
3. Для каждой мажорной версии создается ветка разработки нового (дополнительного функционала). Для текущей мажорной версии это ветка master, для прошлых мажорных версий ветки разработки называются по шаблону: dev-v-m, где m – номер мажорной версии. Работа с этой веткой аналогична работе с веткой master. Для каждой ветки dev-v-m создается своя база данных и именуется по шаблону project_name_dev_v_m. Ветка разработки для мажорной версии создается сразу после начала работы над следующей мажорной версии.
4. Каждая задача – это новая тематическая ветка, которую должен создать разработчик перед началом выполнения задачи. Ветки создаются на основании текущего коммита ветки в которой должна быть выполнена задача. Ветки именуются по шаблонам:
a. t-xxxxx, если это задача на разработку нового функционала (xxxxx – номер задачи из корпоративной системы)
b. b-xxxxx, если это задача по исправлению бага (xxxxx – номер задачи из корпоративной системы).
5. После выполнения задачи и помещения коммитов тематической ветки в веткку, для которой выполнялась задача, разработчик удаляет тематическую ветку.
6. При постановке задачи на исправление бага нужно указывать минорную версию, в которую нужно вносить изменения, например, в версию v-1-1 (если ничего не указано, то баг исправляется в тестируемой на данный момент минорной версии). При исправлении бага в ветке master, главный технолог должен принимать решение о необходимости включения этого исправления в ветку с актуальной версией. Задачи по добавлению функционала предполагают помещение их в ветку master по умолчанию, иначе должна быть указана конкретная ветка (ветки) разработки прошлой мажорной версии.
7. Периодически (по мере реализации функционала) формируются минорные версии. Каждая минорная версия – это отдельная ветка. Ветка минорной версии обозначается по шаблону v-m-n, где m – мажорный номер версии, n – минорный номер версии. В рамках версий формируются релизы. Релизы формируются тогда, когда исправлены все обнаруженные баги в тестируемой минорной версии.
Релиз обозначается тегом формата r-m-n-p, где m – мажорный номер версии, n – минорный номер версии, p – номер патча (патч выпускается только для исправления багов). После создания ветки минорной версии в ней правятся только баги. Ветка минорной версии создается главным технологом в момент окончания разработки функционала версии, но до начала основного тестирования. При формировании минорной ветки, нужно дополнять в проекте файл с изменениями в этой версии по отношению к предыдущей.
8. После формирования релизного тега, ветка минорной версии должна быть слита с основной веткой разработки ().
9. После выпуска релиза следующей минорной версии, поддержка предыдущей минорной версии прекращается.
10. В начале работы над проектом нет смысла в создании минорной версии, в которой исправляются только баги, т.к. данная версия не предоставляется внешнему заказчику. Поэтому до формирования первой минорной версии тестирование происходит на базе ветки master и баги исправляются в ней же. На более поздних этапах проекта, когда еще нет необходимости передавать версии, но уже появилась потребность проводить демонстрации можно начать создавать минорные версии, но в этом режиме обнаруженные и исправленные в минорной версии баги должны обязательно исправляться и в ветке разработки (минорная ветка должна сливаться с веткой разработки). При этом демонстрации всегда выполняются на текущем релизе с протестированным функционалом, а не на последних разработках.
11. Небольшую доработку функционала можно вносить в ветки минорной версии, но это только в крайних случаях.
12. Коммиты именуются по следующему правилу: t-#####-taskname или b-#####-bugname.
На рисунке представлен пример стратегии ветвления для условного проекта, который отражает вышеизложенные правила. Рассмотрим пример подробно:
Проект начался с 01.01.17 с создания нового репозитория и инициирующего коммита C1 в ветке master. Ветка master предназначена для основного процесса разработки и добавления нового функционала. Ветка мастер защищенная и никто, кроме главного технолога или его заместителя (далее под главным технологом так же подразумевается и его заместитель) не имеет права вносить в неё изменения.
Для получения первого релиза было запланировано добавить функционал, описанный в задача 1 и 2 в корпоративной системе. Для реализации каждой из задач на основании коммита C1 разработчиками были созданы ветки и названы в соответствии с соглашением о наименовании (t-####) t-1 и t-2. В рамках данных веток были сделаны коммиты (например, в ветке t-1 t-1-C1 и t-1-C2).
После создания функционала в своих ветках разработчики хорошо его протестировали самостоятельно, потому что они профессионалы и хорошие люди и им не наплевать на то, что они делают и на остальной коллектив. После этого разработчики выполняют merge request для своих веток, т.е. сигнализируют технологу, что они закончили свою работу и хотят, чтобы их код был внесен в основную ветку разработки.
Главный технолог отправляет задачу на code review (поручает это другому программисту или производит самостоятельно). Если код не устраивает, то merge request отклоняется, и программист переделывает работу. Если код успешно проходит стадию code review, то главный технолог принимает merge request и в ветке мастер появляются коммиты C2 и С3. После появления этих коммитов в ветке master задачи начали тестировать тестировщики и аналитики ответственные за за задачу. Если были обнаружены ошибки, то задачи возвращаются на переделку, если нет, то задача закрывается в корпоративной системе.
08.01.17 был готов функционал для версии 1-0 и главный технолог принял решение о создании релизной ветки v-1-0. Релизную ветку v-1-0 начала тестировать команда релизного тестирования. Для ветки v-1-0 создается отдельная база. Команда тестироания обнаружила ряд багов и поставила задачи в корпоративной системе.
На основании этих задач были созданы ветки b-1 и b-3 и после исправления багов разработчики сделали merge request’ы в ветку v-1-0. Далее повторяются шаги, описанные выше по обработке merge request и ветке v-1-0 появляются коммиты v-1-0-C1, v-1-0-C2 и v-1-0-C3. Отметим, что в релизной ветке не добавляется новый функционал, а только исправляются ошибки.
Параллельно в ветке master начали разработку нового функционала, который должен войти в версию v-1-1. Далее в ветке master на рис.1 не отражаются ветки задач для добавления функционала, чтобы не засорять схему, коммиты при этом все равно показаны. Обратим внимание, что после коммита C4, был обнаружен баг b-2 и по результатам его исправления разработчик сделал merge-request и в master и в текущую релизную ветку v-1-0, т.к. этот баг встречается в обеих ветках.
01.02.17 релизная ветка v-1-0, была протестирована командой релизного тестирования и главный технолог принял решение, что можно выпустить первый релиз проекта. Был сформирован тег r-1-0-1. И дистрибутив был передан заказчику. Главный технолог принял решения слить ветку v-1-0 с релизной веткой, т.к. баги, которые были в ней исправлены встречаются и в ветке master.
В процессе использования релиза к-1-0-1 заказчик выявил баг b-3 и он был исправлен в ветке v-1-0 и 08.02.17 было выпущено обновление-патч и сформирован тег r-1-0-2. В этот же момент главный технолог принял решение, что функционал для версии v-1-1 наработан и создал следующую релизную ветку v-1-1. В ветке master команда разработчиков начала разрабатывать функционал для мажорного релиза v-2-0. Поддержка ветки v-1-0, продолжалась до момента выпуска нового релиза версии v-1-1. При этом баг b-4, исправленный в ветке v-1-0 главный технолог решил не помещать в ветку master, т.к. в ней он оказался не актуален, в связи с переделкой модуля, в котором встречался.
04.03.17 командой разработки был выпущен релиз версии r-1-1-1. Одновременно с этим руководство приняло решение сменить основную версию продукта с 1 на 2. Поскольку необходимость добавлять функционал в версию v-1 может остаться, то была создана отдельная ветка разработки (dev-v-1) для первой версии (для нее была создана отдельная база данных). Ветка dev-v-1 является аналогом ветки master, но для версии v-1. При этом поддержка версии v-1-0, была прекращена, т.к. ей на смену пришла версия v-1-1.
15.03.17 был накоплен функционал для v-2-0 и была создана ветка v-2-0.
18.03.17 был накоплен функционал для выпуска нового релиза версии v-1 и была создана релизная ветка v-1-2.
01.04.17 были выпущены релизы версии v-1 (r-1-2-1) и версии v-2 (r-2-0-1). В этот момент также была прекращена поддержка v-1-1, т.к. ей на смену пришла версия v-1-2.
Источник: temofeev.ru
Что такое мажорная и минорная версии программного обеспечения
Нумерация версий современного программного обеспечения обычно выглядит вот так (наиболее распространенная на сегодняшний день система):
ProgramName v. AAAA.BBBB.CCCC
- AAAA — это мажорная версия. Мажорные версии затрагивают серьезные и порой кардинальные изменения приложения.
- BBBB — это минорная версия. Минорные версии затрагивают менее значительные улучшения и доработки софта.
- CCCC — это версия сборки, которая чаще всего «отвечает» / обозначает исправление багов (ошибок) в программе.
Пример подобной схемы нумерации можно наблюдать у утилиты для сжатия / оптимизации размеров изображений RIOT (Radical Image Optimization Tool):
Более подробную и развернутую информацию по этой теме вы можете найти в Википедии:
Источник: red-book-cms.ru