談談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
• 須要操心多個分支