Что такое минорная версия
Нумерация версий программы
У многих начинающих разработчиков возникает вопрос: как назначать версию своей программы?
Поделюсь своим опытом.
Не буду вдаваться в теорию, тем более, что жестких рамок в данном вопросе нет. В своей практике я встречал много различных вариантов назначения версий программ.
Приведу несколько примеров написания версии:
Разберем каждое значение.
Ревизия (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 — окончательная (финальная) версия программы. Используется крайне редко, обычно просто опускается.
Какую схему наименования версий использовать решать прежде всего разработчикам, главное, чтобы нумерация была удобна в разработке и понятна конечному пользователю. И это один из тех вопросов, о которых необходимо договариваться в самом начале разработки любого проекта.
Версионирование ПО
Видов программ великое множество, и все они сильно друг от друга отличаются. Со временем даже одна система может развиться так, что ее станет не узнать. Как же разобраться во всем этом хаосе? Одним из решений является “Версионирование ПО”, с которым мы познакомимся в этой статье.
Польза от версионирования ПО
Применение версионирования решает следующие основные задачи разработки и сопровождения ПО:
Семантическое версионирование
Представьте, что вы используете пакет для обработки изображений в своей системе “Галерея фотографий”. Вся логика галереи всецело зависит от этого пакета, но пакет часто меняется, в нем появляются новые функции и закрываются старые баги, что постоянно изменяет его версию. Вы конечно же хотите “идти в ногу со временем” и часто обновляете этот пакет, но в один ужасный день вся система перестает работать. Быстрый анализ показывает, что проблема вызвана удалением из пакета одной старой, но используемой галереей функции (назовем ее crop ).
Как же обезопасить свой код от такого рода проблем? Решение есть, оно называется “Семантическим версионированием”. Использование систем, применяющих эту модель версионирования, обеспечивает вас удобным инструментом для контроля за возможными изменениями и совместимостью. Работает это очень просто, нужно всего навсего следовать следующим правилам при выборе версии ПО:
Чтобы было понятнее, рассмотрим несколько примеров:
Если вы увидите, что для используемого вами пакета обработки изображений ImageEditor 1.1.4 изменилась версия до 1.1.5 (патч-версия), смело обновляйте ее, ведь это не нарушит совместимости с вашей галереей.
Альфа, бета и другие имена версий
Список изменений
Для отслеживания изменений в версиях применяются файлы “Логов изменений” ( Changelog ), в которых описываются правки, сгруппированные по версиям. При выпуске новой версии ПО этот файл дополняется соответствующими этой версии изменениями. Каждая группа в этом файле, как правило, состоит из четырех подгрупп:
Взгляните на этот файл на примере пакета Zend-Diactoros.
Что такое минорное обновление: как производится и зачем
Минорное обновление — это один из способов усовершенствовать функциональность работающей программной системы, котор ый обязательно сопровождает программное обеспечение в процессе его жизнедеятельности.
Выход обновлений любого программного продукта является неотъемлемой частью его развития и процветания. Апгрейд программного продукта может содержать:
решение технических проблем;
устранение опасных уязвимостей;
добавление новых функциональных возможностей;
адаптаци ю под новые устройства или платформы;
Минорное обновление — это часть планового внесения изменений
Различают несколько видов внесения изменений в программу:
Минорное обновление. Это уже более массивное усовершенствование системы, которое несет в себе более масштабные изменения в программе, однако не предполагает полноценную смену версии программы. В таких корректировках системы внедряется новый функционал: новая игровая карта, новый режим, новый инструмент и др.
Мажорное обновление. В подобном виде апгрейда происходит комплексное изменение программы, вплоть до ее полной неузнаваемости.
«2.0» — версия программы или мажорное обновление второго поколения;
«1» — версия минорного обновления;
«7» — номер примененного патча.
Например, та же программа может быть версии «2.0.2.8», где сохраняется второе поколение программы, но вн осятся изменени я в виде минорного обновления «2» и патча «8». Если программа будет начинаться на «3.0», то это будет означать, что внесены кардинальные обновления.
Как минорное обновление влияет на пользователей
Чтобы правильно оценить масштабы вероятных изменений в категориях апгрейда, приведем пример:
патч может затронуть только одну строчку кода, чтобы исправить какой-то баг;
при мажорном внесении изменений может произойти смена языка программирования всего проекта или игрового движка в игре.
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Версионность веб-приложений
Общеизвестно, что каждый программный продукт в конечном итоге обретает номер поставляемой версии. Изначально это может быть цифра в README файле, на борде в JIRA либо просто в голове у тимлида или ПМа. Но в какой-то момент становится понятно, что нужно формализовать процесс назначения версии релизу, отобразить номер в приложении, интегрировать версионность в CI, аналитику и другие места.
С появлением технологии PWA, версионность в вебе обрела еще больший смысл, ведь теперь самая последняя версия приложения доступна пользователю не в момент загрузки страницы, а только через определенное время после обновления файлов в фоновом режиме. Поэтому важно следить за номерами версий у пользователей, чтобы знать в какой из них возникла проблема и сколько обновилось до последней.
Ниже рассмотрим способы добавления версионности веб-проекту, используя готовые решения, и напишем свой универсальный скрипт, удовлетворяющий всем требованиям.
Git и версионность
Для наглядности, давайте взглянем на диаграмму одного из самых популярных подходов Git Flow:
Демонстрация Git Flow
Расшифровка версии semver
Очевидно, что версии в первую очередь должны быть привязаны к коммитам (после которых и собираются релизные сборки), чтобы хранилась наглядная история релизов и легко было откатываться до предыдущего при необходимости. Удобнее всего это реализовать с помощью тегирования коммитов (git tag). Давайте рассмотрим npm пакеты, помогающие решить эту задачу.
Готовые npm-решения
Основная проблема в том, что все существующие npm пакеты предназначены больше для версионности и публикации вашего проекта в npm непосредственно, хотя никто не мешает воспользоваться функционалом инкрементирования версии сборки и пуша тегов в гит (будь то ручной запуск команды, либо из CI-скрипта).
Примеры:
Обновление версии с помощью одной команды
Нет возможности контролировать, куда записывается номер версии (только в package.json)
Нет возможности добавить постфикс версиям (например, 1.3.1-dev, 0.1.1-alpha)
Не все git сервисы разрешают пушить тег с новой версией и измененный package.json в репозиторий прямо из CI-скрипта после окончания сборки.
Пакет популярнее предыдущего, больше конфигураций, интерактивный режим настройки. Принцип выполнения команды такой же:
Для режима CI нужно добавить флаг —ci
Нет возможности добавить постфикс к версии (по крайней мере я не нашел)
Наиболее популярный из представленных примеров. Полностью автоматизирует процесс версионности, убирая человеческий фактор по инкременту версий. Однако, для этого необходимо следовать Commit Message Conventions (хороший повод начать именовать коммиты более организованно).
Вдобавок, на основе коммитов генерируется changelog.
Возможность контролировать процесс обновления мажорных и минорных версий вручную.
Как видим, готовых решений достаточно, однако, давайте все же попробуем написать свое, адаптировав его под свои нужды.
Что нам нужно?
Код из git-веток попадающий на окружение (dev, staging, prod) должен быть пронумерован и хранить тип окружения (к примеру, 1.0.1-dev)
Каждый пуш в ветку (master, integration, release) увеличивает патч-версию
Обновление мажорной и минорной версии происходит вручную после каждого релиза / спринта. Какую версию менять решаем сами на основе запланированных задач и потенциальных изменений
Версия сборки доступна в JS, для того чтобы была возможность ее отображать в самом приложении, использовать для аналитики, передавать в системы репорта ошибок и т.п.
package.json не должен меняться во время CI (т.е версию приложения не храним в этом файле) во избежание потенциальных мерж конфликтов (к примеру, когда одновременно вмерживается несколько реквестов и сборки собираются одновременно, в нашей команде такое случается достаточно часто).
При релизе патч-версия (z) начинается с 1, оставляя только номер релиза (x.y). Например: версии на деве 1.4.1-dev, 1.4.2-dev, 1.4.3-dev, а в релиз пойдет 1.4.1. Если же подливаем hotfix в тот же релиз, то версия будет 1.4.2.
Данные пункты являются субъективными и легко могут быть изменены под ваши требования. Ниже рассмотрим JS-реализацию данной логики.
Реализация своей системы версионности
Предварительно создадим 2 файла, первый version.txt (в корне проекта) для хранения мажорной и минорной версии релиза (которые мы вручную меняем, как указано выше). В файле будет хранится только 2 числа версии, разделенные точкой вида: 2.13
Это позволит получить доступ к версии прямо во время выполнения javascript / typescript кода приложения и использовать по назначению:
Логика определения и назначения версии будет следующая:
получить текущую мажорную и минорную версии (x.y) из файла version.txt
вывести список всех git-тегов данного релиза x.y.*
обнаружить патч версию (z) последнего тега релиза
добавить новый тег вида x.y.(z+1)
при необходимости добавить постфикс окружения (x.y.z-dev)
Скрипт генерации новой версии приложения на основе предыдущих версий из git готов. Далее можно запускать сборку проекта, зная, что app-version.js с новой версией попадет в проект и будет доступен в JS.
Создаем еще один файл push-new-version-tag.js:
Готово. Остается добавить запуск этих команд в ваш CI скрипт.
А вот как выглядит наш для GitLab (проект на Angular):
Как мы используем номер версии в Uxcel?
Наше приложение является PWA, поэтому нам важно следить за номерами версий наших пользователей: версии отправляются в google analytics, в систему мониторинга ошибок sentry, в API запросы (которые могут обрабатываться по-разному в зависимости от версии) и, само собой, версия отображается в самом приложении. Помимо этого, номер версии может использоваться для отображения Release Notes или для показа обучающего окна нового функционала сразу после авто-обновления приложения.
Спасибо за внимание, надеюсь, статья была полезной для вас! Буду рад услышать ваше мнение, делитесь своими способами версионности веб-приложений.
Семантическое управление версиями 1.0.0-rc.1
В мире разработки программного обеспечения, существует страшное место, называемое «ад зависимостей». Чем больше ваша система, тем больше шанс, что в один из дней вы попадете в эту ловушку.
В системе с большим количеством зависимостей, выпуск новых пакетов может быстро превратиться в кошмар. Если зависимости слишком прочные, вы не можете обновить пакет, не обновив при этом версии всех зависимых пакетов. Если зависимости слишком свободные, у вас возникнут проблемы с распущенностью версий. «Ад зависимостей», это когда слишком прочные, или наоборот, слишком свободные зависимости не дают вам легко и безопасно развивать ваш проект.
Как решение этой проблемы, я предлагаю простой набор правил, которые диктуют как присваивать и увеличивать номера версий. Для того, что бы система работала, для начала, вам нужно объявить открытый API. Это должен быть простой и ясный документ. Рассмотрим номер версии в формате X.Y.Z (Major.Minor.Patch).
При исправление ошибок не затрагивающих API увеличивается Patch версия. При добавление или изменение API с сохранением обратной совместимостью увеличивается Minor версия. Если API изменяется без сохранения обратной совместимости, то увеличивается Major версия.
Я называю эту систему «Семантическое управление версиями». Согласно этой схеме, номера версий и то, как они меняются несут в себе смысл об основном коде и о том, как он изменялся от версии к версии.
Спецификация Семантического управления версиями
Ключевые слова «ДОЛЖЕН (MUST)», «НЕ ДОЛЖЕН (MUST NOT)», «СЛЕДУЕТ (SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)», «МОЖЕТ (MAY)», в этом документе должны интерпретироваться в соответствии с RFC 2119.