假设有一个地方一个源代码控制系统,当一个产品(在这种情况下安装程序版本1)发布。
发布工程师将拍摄“发布分支”状态的快照,然后相应地为下一个版本(本例中为安装程序版本2)重新命名。
开发人员将继续在类似的分支(Dev分支)中编码,该分支具有相同的位直到发布日期。
从此“Release/Dev”分支中创建HotFixes/Patches分支,并从“热修复或修补程序”分支中释放修补程序。
这些补丁包含确定安装前需求的逻辑。例如,“patch1-version1”需要“Release1版本”...“patch2-version1”需要的可能只是“patch1-version1”...等等。
当您准备创建第二版本“Release版本2“时,发布分支将被相应地命名并且将具有”发布版本1“+”所有修补程序“在”修补程序或修补程序“分支中的所有更改。
这个新版本需要逻辑来卸载以前的版本并安装新版本。
现在,从最新的“Release Branch”创建一个新的“Hot Fixes”分支,或者将这些更改简单地拖放到之前创建的“Hot Fixes”分支,以及任何用于“发行版本2 “现在应该更新了逻辑,只允许安装新的需求......与”发布版本2“有关的那些。
例如,“Patch1-ReleaseVersion2”将要求存在“Release Version2”...类似地,“Patch2-ReleaseVersion2”可能需要“发布版本2”加上第一个发布的补丁,或者只需要发布第一个补丁,因为基本版本(发布版本2)也必须在那里。
因此,根据此标准,“patch1,2,3 ... n-ReleaseVersion2”不应该安装在任何具有“发行版本1”+零/更多修补程序的服务器上,因为修补程序安装程序中的逻辑不会(或不应该)允许这样的事情。