Предполагается, что на момент выпуска продукта (в данном случае установщика версия 1) установлена система контроля версий.
Релиз-инженер сделал бы снимок состояния «Релиз-ветки», а затем переименовал его соответствующим образом для следующего выпуска (в данном случае установщик версии2).
Разработчики будут продолжать кодировать в аналогичной ветви (ветке Dev), которая имеет те же биты до даты выпуска.
Из этой ветки "Release / Dev" создается ветка HotFixes / Patches, а патчи выпускаются из ветки "Hot Fixes or Patches".
Эти патчи будут содержать логику, которая будет определять предварительные требования для установки. Например, для «patch1-version1» потребуется «Release version1» ... «patch2-version1» может потребоваться просто «patch1-version1» ... и т. Д.
Когда вы будете готовы создать второй выпуск "Release Version2", ветвь Release будет названа соответствующим образом и будет иметь все изменения из "Release Version1" + "All fixes" в ветке "Hot Fixes or Patches".
В этом новом выпуске потребуется логика для удаления предыдущего выпуска и установки нового.
СЕЙЧАС, новая ветка «Горячих исправлений» создается из современной «Ветки релизов», или изменения просто переносятся в ранее созданную ветвь «Горячих исправлений» и любые новые патчи для «Версии выпуска 2». теперь должен иметь обновленную логику, чтобы ТОЛЬКО разрешить установку в соответствии с новыми требованиями ... относящимися к "Release Version2".
Например, «Patch1-ReleaseVersion2» потребует наличия «Release Version2» ... аналогично, «Patch2-ReleaseVersion2», вероятно, потребует и «Release Version2» плюс первый выпущенный патч, или просто наличие первого патча выпущен, потому что базовый выпуск (Release Version2) также должен быть там.
Таким образом, учитывая этот стандарт, "patch1,2,3 ... n-ReleaseVersion2" никогда не следует устанавливать на сервер, на котором установлены исправления "Release Version1" + Zero / More, поскольку логика в установщике исправлений не будет ( или не должны) разрешить такую вещь.