Политика релизов Tarantool

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

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

Релизная серия – это ряд версий для разработки и производственной эксплуатации. Эта последовательность версий линейно развивается по определенному плану. У каждой серии свой жизненный цикл, а версии в ней обладают некоторой гарантией совместимости друг с другом и с версиями других серий. Срок поддержки каждой серии – минимум один год с выхода первого релиза.

Релизная версия, или релиз – это тщательно протестированный и готовый к производственной эксплуатации дистрибутив Tarantool, привязанный к определенному коммиту. Номер релиза состоит из трех частей:

 
MAJOR.MINOR.PATCH

Каждое число соответствует одному из трех типов релизных версий, о чем подробно рассказано ниже.

Мажорная релизная версия – это первый релиз в своей релизной серии. Релиз включает в себя новую функциональность и может нарушать обратную совместимость с прежними версиями. Каждый следующий мажорный релиз получает номер, в котором изменено первое число:

 
MAJOR.0.03.0.0

В минорном релизе могут вводиться новые функциональные возможности. Тем не менее он гарантированно будет совместим с более ранними версиями серии. Могут быть также исправлены ошибки. Каждый следующий минорный релиз получает номер, в котором изменено второе число:

 
MAJOR.MINOR.03.1.03.2.0

Патч (patch release) исправляет ошибки предыдущих версий, но не добавляет новую функциональность. Каждый следующий патч получает номер, в котором изменено третье число:

 
MAJOR.MINOR.PATCH3.0.13.0.2

Релизы отвечают ряду требований:

• Релиз прошел предварительное тестирование и внедрение во внутренних проектах, после чего не осталось сомнений в его стабильности.

• Нет известных ошибок в типичных сценариях использования.

• Нет регрессий по сравнению с предыдущим релизом или релизной серией (в случае мажорного релиза).

Обратная совместимость гарантируется между всеми версиями в одной релизной серии. Желательна, но не гарантируется между разными релизными сериями (при изменении мажорного номера). Подробнее см. на странице гарантий совместимости.

Предварительными называются версии, опубликованные для тестирования и обкатки, но не предназначенные для производственной эксплуатации. Эти версии нумеруются по тому же принципу, что и релизы, но имеют суффикс:

 
MAJOR.MINOR.PATCH-suffix

Ниже подробно рассказывается о четырех типах предварительных версий.

Dev-сборка (development build) отражает определенный этап разработки продукта. Такие сборки используются только в процессе разработки и внутреннего тестирования.

Dev-сборки обозначаются суффиксом, полученным командой $(git describe --always --long)-dev:

 
MAJOR.MINOR.PATCH-describe-dev2.10.2-149-g1575f3c07-dev3.0.0-alpha1-14-gxxxxxxxxx-dev3.0.0-entrypoint-17-gxxxxxxxxx-dev3.1.2-5-gxxxxxxxxx-dev

В альфа-версию (alpha version) включена часть функциональных возможностей, запланированных в релизной серии. Альфа-версия может быть неполной или нестабильной, а также не обладать обратной совместимостью с предыдущей серией.

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

 
MAJOR.MINOR.PATCH-alphaN3.0.0-alpha13.0.0-alpha2

В бета-версию (beta version) включены все функциональные возможности, запланированные в релизной серии. Бета-версия подходит, чтобы начать разработку нового приложения.

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

 
MAJOR.MINOR.PATCH-betaN3.0.0-beta13.0.0-beta2

Отметим, что разработка 2.10.0, первого релиза по новой политике, начинается с версии 2.10.0-beta1.

В релиз-кандидате (release candidate, RC) исправляются ошибки и совершенствуется функциональность. Он также помогает собирать отзывы перед публикацией релиза. Набор функциональных возможностей в релиз-кандидате такой же, как в бета-версии. Известные ошибки в типичных сценариях использования устранены, регрессионных ошибок нет.

Релиз-кандидат подходит для использования в предпроизводственной среде (staging).

 
MAJOR.MINOR.PATCH-rcN3.0.0-rc13.0.0-rc23.0.1-rc1

Каждая релизная серия проходит три стадии:

Стадия ранней разработки (early development) продолжается до выхода мажорного релиза. На этой стадии публикуются альфа- и бета-версии, а также релиз-кандидаты.

Стадия разделена на два этапа:

1. Разработка новой функциональности через альфа- и бета-версии. На этом этапе функциональные возможности могут добавляться и иногда удаляться.
2. Стабилизация начинается с выхода первой версии релиз-кандидата. На этом этапе набор функциональных возможностей не меняется.

Эта стадия начинается, когда выходит первый релиз. Теперь в релизной серии могут появляться только изменения, не нарушающие обратную совместимость.

На этой стадии устраняются известные проблемы безопасности и исправляются регрессионные ошибки, возникшие в серии.

Патчи для регрессионных и других видов ошибок выпускаются, пока серия не перейдет со стадии поддержки на стадию прекращения поддержки (end of life, EOL).

Решение о том, исправить ли конкретную ошибку в релизной серии, принимается в зависимости от того, насколько проблема серьезна, сложно ли будет ее устранить в предыдущих версиях и нарушит ли исправление обратную совместимость.

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

В течение периода поддержки в релизной серии выпускаются обновления для новых версий дистрибутивов Linux.

Срок поддержки для каждой серии – как минимум один год.

Стадия прекращения поддержки (end of life, EOL) для серии наступает, когда опубликован последний релиз в этой серии. После этого серия прекращает обновляться.

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

Стадия прекращения поддержки для релизной серии может наступить только тогда, когда большинство производственных сред, с которыми Tarantool работает по SLA и другим соглашениям, обновится до более новой серии.

Дата окончания технической поддержки (EOS) наступает позже даты EOL. Когда серия достигает EOS, команда Tarantool прекращает техническую поддержку и не обрабатывает обращения, связанные с поддержкой.

Рекомендуется отслеживать календарь и планировать обновление версии Tarantool до наступления даты EOS.

На стадии ранней разработки последовательность версий в релизной серии может быть такой:

 
3.0.0-alpha13.0.0-alpha2...3.0.0-alpha73.0.0-beta1...3.0.0-beta53.0.0-rc1...3.0.0-rc43.0.0 (release)

Как только выпущен первый релиз, серия переходит на стадию поддержки. Дальнейшие версии могут быть опубликованы в такой последовательности:

 
3.0.0 (release of a new major version)3.0.1-rc1...3.0.1-rc43.0.1 (release with some bugs fixed but no new features)3.1.0-rc1...3.1.0-rc63.1.0 (release with new features and, possibly, extra fixed bugs)

Со временем стадия поддержки подходит к концу, и релизная серия выходит на стадию прекращения поддержки (end of life, EOL). С этого момента новые версии не выпускаются.