谈谈patch strategy

所谓的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
  • 需要操心多个分支

 

posted @ 2013-08-24 16:20 lzprgmr 阅读(...) 评论(...) 编辑 收藏

黄将军