所谓的patch strategy，就是软件发布后出现bug时打补丁的方式 - 主要是关于源代码branch如何组织的方式
针对项目的开发阶段、开发状态、维护方式不同，可以有不同的patching strategy
一、trunk - release
- 新版本从release branch发布
- 适合只需维护最新版本的情况 - 一般工具类型的项目
- 适合有较多的开发者在trunk上check-in代码的情况，因为trunk可能不太稳定，而且包含一些不想release的代码
- 需要release时，从trunk分支选择需要的feature，integrate到release分支并发布
- 同时，开发者继续在trunk上开发新feature
- 如果新的发布版本有bug，在release分支上fix并重新发布，然后将fix integrate回trunk
- 每次release，都要折腾release分支
二、trunk - patch
- 新版本从trunk分支发布
- 适合只需维护最新版本的情况 - 一般工具类型的项目
- 适合开发者较少，代码改变不太大的情况，trunk的状态相对比较稳定。
- 需要release时，直接从trunk分支release出去，最好打个label
- 同时，开发者继续在trunk上开发新feature
- 如果新的发布版本有bug，将代码从trunk分支integrate到patch分支，以上次发布的label为准，在patch分支fix并发布，然后将fix integrate回trunk
- 如果没有production breakage，你无需关心patch分支
三、trunk - trunk_<version>s
- 新版本从一个新的branch出去
- 适合需要维护多个版本的情况 - 你可能需要在之前发布的几个版本上fix不同的bug - 一般为library类型的项目
- 需要release时，从trunk分支integrate到trunk-<version>，并从trunk-<version>分支发布
- 同时，开发者继续在trunk上开发新feature
- 如果某个版本有bug，在该特定分支上fix并发布，然后将fix integrate回trunk
- 需要操心多个分支