Версия:

Управление версиями

Управление версиями

Политика управления версия

Версия Tarantool’а определяется тремя цифрами, например, 1.7.7. Мы пользуемся цифрами по определению, данному на сайте http://semver.org:

  • Первая цифра означает МАЖОРНУЮ версию. Мажорная версия может содержать несовместимые изменения.
  • Вторая цифра означает МИНОРНУЮ версию; такая версия не содержит несовместимых изменений и используется для релиза нового функционала с обратной совместимостью.
  • Третья цифра используется для ПАТЧ-версий, которые содержат только исправления дефектов с обратной совместимостью.

Цифра МИНОРНОЙ версии также отражает ее стабильность:

  • 0 означает альфа-версию,
  • 1 означает бета-версию,
  • от 1 до 10 означает стабильную версию, а
  • 10 означает окончательную версию с долгосрочной технической поддержкой.

Таким образом, каждая МАЖОРНАЯ версия проходит через жизненный цикл разработки МИНОРНЫХ версий следующим образом:

  1. Альфа. Один раз в несколько месяцев выходят несколько альфа-версий, например, 2.0.1, 2.0.2.

    Альфа-версии могут содержать несовместимые изменения, сбои и другие дефекты.

  2. Бета. Когда готовы значительные изменения, необходимые для включения новых основных функций, мы выпускаем несколько бета-версий, например, 2.1.3, 2.1.4.

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

  1. Стабильная. Наконец, после того, как бета-версии успешно отработают примерно несколько месяцев, во время которых мы исправляем поступающие дефекты и добавляем некоторые небольшие функции, мы объявляем эту МАЖОРНУЮ версию стабильной.

Как и в Ubuntu, мы различаем два вида стабильных версий:

  • LTS (Long Term Support - Долгосрочная техническая поддержка) такие версии поддерживаются в течение 3 лет (сообщество) и до 5 лет (платежеспособные клиенты). LTS-версию можно идентифицировать по МИНОРНОЙ версии = 10.
  • Стандартные стабильные версии поддерживаются в течении нескольких месяцев после выхода.

«Support» (поддержка) означает, что мы продолжаем исправлять ошибки в этой версии.

Мы добавляем коммиты одновременно в три МАЖОРНЫЕ версии:

  • LTS – это стабильная версия, которая не получает новые функции, а только исправления обратной совместимости. Следовательно, по правилам семантической версификации в LTS-версии никогда не увеличивается МАЖОРНАЯ или МИНОРНАЯ, а только ПАТЧ-версия.
  • СТАБИЛЬНАЯ – это наша текущая стабильная версия, в которую могут быть добавлены новые функции. Когда выходит следующая СТАБИЛЬНАЯ версия, увеличивается МИНОРНАЯ версия. Между МИНОРНЫМИ версиями у нас могут увеличиваться промежуточные уровни ПАТЧ-версии, в которых будут только исправлены дефекты. Мы поддерживаем ПАТЧ-уровни для двух СТАБИЛЬНЫХ версий – текущей и предыдущей – для сообщества разработчиков.
  • СЛЕДУЮЩАЯ – это следующая МАЖОРНАЯ версия, которая проходит процесс зрелости, описанный в начале раздела. Когда СЛЕДУЮЩАЯ версия находится в альфа-стадии, МИНОРНАЯ остается на уровне 0 и увеличивается, когда версия переходит в БЕТА-стадию. После того, как СЛЕДУЮЩАЯ версия становится СТАБИЛЬНОЙ, мы переключаемся на выдачу небольших функций, обозначая предыдущую стабильную версию как LTS, и выпускаем ее с МИНОРНОЙ версией = 10.

Итак, раз в квартал выходят:

  • следующая LTS-версия, например, 2.10.6, 2.10.7 или 2.10.8
  • следующая СТАБИЛЬНАЯ версия,например, 3.6, 3.7 или 3.8
  • (возможно) альфа-стадия или бета-стадия СЛЕДУЮЩЕЙ версии, например, 4.0.1, 4.0.2 или 4.0.3

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

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

Пример идентификатора версии:

  • 2.0.3 - третья альфа-стадия версии 2.0
  • 2.1.3 - бета-стадия версии 2.0
  • 2.2 - стабильная версия серии 2.0, но еще не LTS
  • 2.10 - LTS-версия

Как собрать минорную версию

$ git tag -a 2.4 -m "Next minor in 2.x series"
 $ vim CMakeLists.txt # редактировать CPACK_PACKAGE_VERSION_PATCH
 $ git push --tags

Тег, который делается на ветке git, можно забрать при слиянии или оставить на ветке. Метод «сохранить тег на ветке, на которой он был первоначально установлен», заключается в использовании --no-fast-forward при слиянии этой ветки.

С помощью --no-ff создается набор изменений при слиянии для пояснения полученных изменений, и только этот набор изменений при слиянии оказывается в ветке назначения. Этот метод можно использовать, когда есть две активные линии разработки, например, «стабильная» и «следующая», и необходимо иметь возможность помечать тегами линии независимо друг от друга.

Чтобы убедиться, что тег не окажется в ветке назначения, необходимо, чтобы коммит, к которому привязан тег, остался в исходной ветке. Это и происходит при отключенном «fast-forward» – создается коммит для слияния и добавляется в обе ветки.

Вот как это может выглядеть:

kostja@shmita:~/work/tarantool$ git checkout master
 Already on 'master'
 kostja@shmita:~/work/tarantool$ git tag -a 2.4 -m "Next development"
 kostja@shmita:~/work/tarantool$ git describe
 2.4
 kostja@shmita:~/work/tarantool$ git checkout master-stable
 Switched to branch 'master-stable'
 kostja@shmita:~/work/tarantool$ git tag -a 2.3 -m "Next stable"
 kostja@shmita:~/work/tarantool$ git describe
 2.3
 kostja@shmita:~/work/tarantool$ git checkout master
 Switched to branch 'master'
 kostja@shmita:~/work/tarantool$ git describe
 2.4
 kostja@shmita:~/work/tarantool$ git merge --no-ff master-stable
 Auto-merging CMakeLists.txt
 Merge made by recursive.
  CMakeLists.txt |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 kostja@shmita:~/work/tarantool$ git describe
 2.4.0-0-g0a98576

Кроме того, следует помнить:

  1. Обновляйте все задачи. Обновляйте журнал изменений ChangeLog на основании вывода git log.

    Журнал изменений ChangeLog должен включать в себя только пункты, указанные в задачах на GitHub. Если что-то значительное не указано, значит, что-то пошло не так при планировании версии, и ее выход следует отложить до выяснения причин.

  2. Нажимайте „Release milestone“ (создать промежуточную версию). Создавайте промежуточные версии для следующей минорной версии. Указывайте драйверу на дефекты и проекты для новой промежуточной версии.

Как выпустить Docker-контейнер

Чтобы выдать новую версию Docker-контейнера:

  1. On the master branch of tarantool/docker repository, find the Dockerfile that corresponds to the commit’s major version (e.g. https://github.com/tarantool/docker/blob/master/2.x/Dockerfile for Tarantool version 2.4) and specify the required commit in TARANTOOL_VERSION, for example TARANTOOL_VERSION=2.4.0-11-gcd17b77f9.

    Снова загрузите Dockerfile в главную ветку.

  1. In the same repository, create a branch named after the commit’s <major>.<minor> versions, e.g. branch 2.4 for commit 2.4.0-11-gcd17b77f9.

  2. В настройках сборки контейнера Tarantool’а в hub.docker.com (https://hub.docker.com/r/tarantool/tarantool/~/settings/automated-builds/) добавьте новую строку:

    Branch: x.y, /x, x.y
    

    где x и y соответствуют мажорной и минорной версиям коммита.

    Нажмите Save changes (сохранить изменения).

Вскоре будет создан новый Docker-контейнер.