Point branches

Постановка проблемы

Сейчас в рамках платформы существуют бранчи pN и cN, раньше существовал также бранч tN. Эти бранчи должны характеризоваться существенно различным release management, однако, как минимум, обновления по безопасности должны попадать в них во все. Таким образом, мы не можем использовать один бранч для обычных и сертифицированных дистрибутивов, однако полностью раздельная поддержка нескольких бранчей требует много работы и снижает качество результата. Так, для бранчей под сертификацию требуется следующий цикл работы (не реализован сейчас, что доставляет определённые неудобства, которые могут в любой момент стать серьёзными проблемами):

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

И так ad infinitum

Сейчас у нас функциональные улучшения неизбежно смешиваются с исправлениями по безопасности, так как бранч cN у нас один и для того и для другого. В результате мы очень ограничены в возможностях делать функциональные улучшения.

Применимость для старых бранчей cN

Для реализации этой схемы желательна реализация Binary_package_identity_change, однако, вовсе не обязательна. Просто у point branches серии cN будет одинаковый суффикс и при этом для них должно быть прописано старшинство, то есть пакеты, собираемые в бранч c7.2 должны иметь большие версии, чем в c7.1. Ну и так ветвление должно осуществляться не от общего бранча pN, а от предыдущего point branch