Автоматизированное семантическое управление версиями с помощью GitVersion

¶Семантическое версионирование в Drupal

Drupal всегда использовал некое подобие семантического версионирования {drupal_core}-{major}.{minor}. То есть, ядро и модули были лишены патч версии, и все обновления поступали в минорной версии. Это могло вызывать некоторые сложности и не всегда понятно, чего ожидать от релиза, зная лишь новую версию.

Начиная с Drupal 8 в ядре адаптировали семантическое версионирование. Таким образом, начиная с данной мажорной версии друпала, именование ведётся в соответствии с данной спецификацией.

При нумерации версий ядра используются только {major}.{minor}.{patch}-{pre_release}. Единственное что может броситься в глаза, это то, что пред-релизное именование у нас ведётся без точки: alpha1, beta2, rc3, вместо того как это приводится в примерах alpha.1, beta.2, rc.3. Тем не менее это соответствует спецификации, но не забывайте о данной особенности когда будете именовать свои релизы!

Видео

Спецификация Семантического Версионирования (SemVer)

Слова «ДОЛЖЕН» (MUST), «НЕ ДОЛЖЕН» (MUST NOT), «ОБЯЗАТЕЛЬНО» (REQUIRED), «СЛЕДУЕТ» (SHOULD), «НЕ СЛЕДУЕТ» (SHOULD NOT), «РЕКОМЕНДОВАННЫЙ» (RECOMMENDED), «МОЖЕТ» (MAY) и «НЕОБЯЗАТЕЛЬНЫЙ» (OPTIONAL) в этом документе должны быть интерпретированы в соответствии с RFC 2119.

  1. ПО, использующее Семантическое Версионирование, должно объявить публичный API. Этот API может быть объявлен самим кодом или существовать строго в документации. Как бы ни было это сделано, он должен быть точным и исчерпывающим.

  2. Обычный номер версии ДОЛЖЕН иметь формат X.Y.Z, где X, Y и Z — неотрицательные целые числа и НЕ ДОЛЖНЫ начинаться с нуля. X — мажорная версия, Y — минорная версия и Z — патч-версия. Каждый элемент ДОЛЖЕН увеличиваться численно. Например: 1.9.0 ->1.10.0 -> 1.11.0.

  3. После релиза новой версии пакета содержание этой версии НЕ ДОЛЖНО быть модифицировано. Любые изменения ДОЛЖНЫ быть выпущены как новая версия.

  4. Мажорная версия ноль (0.y.z) предназначена для начальной разработки. Всё может измениться в любой момент. Публичный API не должен рассматриваться как стабильный.

  5. Версия 1.0.0 определяет публичный API. После этого релиза номера версий увеличиваются в зависимости от того, как изменяется публичный API.

  6. Патч-версия Z (x.y.Z | x > 0) ДОЛЖНА быть увеличена только если содержит обратно совместимые баг-фиксы. Определение баг-фикс означает внутренние изменения, которые исправляют некорректное поведение.

  7. Минорная версия (x.Y.z | x > 0) ДОЛЖНА быть увеличена, если в публичном API представлена новая обратно совместимая функциональность. Версия ДОЛЖНА быть увеличена, если какая-либо функциональность публичного API помечена как устаревшая (deprecated). Версия МОЖЕТ быть увеличена в случае реализации новой функциональности или существенного усовершенствования в приватном коде. Версия МОЖЕТ включать в себя изменения, характерные для патчей. Патч-версия ДОЛЖНА быть обнулена, когда увеличивается минорная версия.

  8. Мажорная версия X (X.y.z | X > 0) ДОЛЖНА быть увеличена, если в публичном API представлены какие-либо обратно несовместимые изменения. Она МОЖЕТ включать в себя изменения, характерные для уровня минорных версий и патчей. Когда увеличивается мажорная версия, минорная и патч-версия ДОЛЖНЫ быть обнулены.

  9. Предрелизная версия МОЖЕТ быть обозначена добавлением дефиса и серией разделённых точкой идентификаторов, следующих сразу за патч-версией. Идентификаторы ДОЛЖНЫ содержать только ASCII буквенно-цифровые символы и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Числовые идентификаторы НЕ ДОЛЖНЫ начинаться с нуля. Предрелизные версии имеют более низкий приоритет, чем соответствующая релизная версия. Предрелизная версия указывает на то, что эта версия не стабильна и может не удовлетворять требованиям совместимости, обозначенными соответствующей нормальной версией. Примеры: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

  10. Сборочные метаданные МОГУТ быть обозначены добавлением знака плюс и ряда разделённых точкой идентификаторов, следующих сразу за патчем или предрелизной версией. Идентификаторы ДОЛЖНЫ содержать только ASCII буквенно-цифровые символы и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Сборочные метаданные СЛЕДУЕТ игнорировать, когда определяется старшинство версий. Поэтому два пакета с одинаковой версией, но разными сборочными метаданными, рассматриваются как одна и та же версия. Примеры: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

  11. Приоритет определяет, как версии соотносятся друг с другом, когда упорядочиваются. Приоритет версий ДОЛЖЕН рассчитываться путём разделения номеров версий на мажорную, минорную, патч и предрелизные идентификаторы. Именно в такой последовательности (сборочные метаданные не фигурируют в расчёте). Приоритет определяется по первому отличию при сравнении каждого из этих идентификаторов слева направо: Мажорная, минорная и патч-версия всегда сравниваются численно. Пример: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. Когда мажорная, минорная и патч-версия равны, предрелизная версия имеет более низкий приоритет, чем нормальная версия. Пример: 1.0.0-alpha < 1.0.0. Приоритет двух предрелизных версий с одинаковыми мажорной, минорной и патч-версией ДОЛЖНЫ быть определены сравнением каждого разделённого точкой идентификатора слева направо до тех пор, пока различие не будет найдено следующим образом: идентификаторы, состоящие только из цифр, сравниваются численно; буквенные идентификаторы или дефисы сравниваются лексически в ASCII-порядке. Численные идентификаторы всегда имеют низший приоритет, чем символьные. Больший набор предрелизных символов имеет больший приоритет, чем меньший набор, если сравниваемые идентификаторы равны. Пример: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

Минорная версия программного обеспечения

Изменение номера минорной версии программного обеспечения происходит при:

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

Первая минорная версия = 0 (версия 1.0 – первый выход продукта на рынок). При выходе новой версии продукта нумерация минорной версии сбрасывается в нулевое значение.

Изменения в сопровождении продукта

Изменения, вошедшие в минорную версию, должны отражаться в документации по продукту, в том числе печатной. При выпуске коробочных продуктов возможна индикация номера минорной версии с помощью наклеек (к примеру «Версия 3.1»), или других средств, не меняя общий дизайн.

Минорная версия продукта может отражаться в части маркетинговых материалов, информации на сайте.

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

Правила использования номера

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

Запуск первой сборки

Пора начинать! Сделаем коммит и отправим наше творение в Azure DevOps, а потом посмотрим, что произойдет в разделе “build pipelines”.

Azure DevOps — пустой раздел конвейеров

Похоже, тут пусто. Файл иногда не попадает в Azure DevOps автоматически.

Давайте добавим конвейер, нажав кнопку создать конвейер. Выберите Azure Repos Git, а затем правильный репозиторий, чтобы сообщить разделу конвейеров Azure Pipelines, где хранятся azure-конвейеры. Теперь конвейеры Azure должны забрать ранее закоммиченный файл конвейеров. Нажмите кнопку запуска, чтобы сделать это вручную.

Azure DevOps — первая успешная сборка!

Примерно через двадцать секунд сборка завершится успешно, и результат будет виден в обзоре. Если посмотреть в колонку “Последний запуск”, то можно найти и первую версию. В нашем случае это будет первая версия по умолчанию, 0.1.0. Поскольку сборка прошла успешно, внутри артефактов Azure также добавляется опубликованный пакет.

Azure DevOps — артефакты для первой сборки

NPM-пакет действительно оказался в Azure Artifacts. Сгенерированный номер версии был соблюден, поскольку в качестве начального номера версии внутри нашего файла package.json установлен 0.0.1.

Теги

Adblock
detector