谈谈patch strategy

所谓的patch strategy，就是软件发布后出现bug时打补丁的方式 - 主要是关于源代码branch如何组织的方式

针对项目的开发阶段、开发状态、维护方式不一样，能够有不一样的patching strategy

1、trunk - release

• 新版本从release branch发布
• 适合只需维护最新版本的状况 - 通常工具类型的项目
• 适合有较多的开发者在trunk上check-in代码的状况，由于trunk可能不太稳定，并且包含一些不想release的代码
• 须要release时，从trunk分支选择须要的feature，integrate到release分支并发布
• 同时，开发者继续在trunk上开发新feature
• 若是新的发布版本有bug，在release分支上fix并从新发布，而后将fix integrate回trunk
• 每次release，都要折腾release分支

2、trunk - patch

• 新版本从trunk分支发布
• 适合只需维护最新版本的状况 - 通常工具类型的项目
• 适合开发者较少，代码改变不太大的状况，trunk的状态相对比较稳定。
• 须要release时，直接从trunk分支release出去，最好打个label
• 同时，开发者继续在trunk上开发新feature
• 若是新的发布版本有bug，将代码从trunk分支integrate到patch分支，以上次发布的label为准，在patch分支fix并发布，而后将fix integrate回trunk
• 若是没有production breakage，你无需关心patch分支

3、trunk - trunk_<version>s

• 新版本从一个新的branch出去
• 适合须要维护多个版本的状况 - 你可能须要在以前发布的几个版本上fix不一样的bug - 通常为library类型的项目
• 须要release时，从trunk分支integrate到trunk-<version>，并从trunk-<version>分支发布
• 同时，开发者继续在trunk上开发新feature
• 若是某个版本有bug，在该特定分支上fix并发布，而后将fix integrate回trunk
• 须要操心多个分支