剛剛過節回來，XY便找我討論配置管理計劃，我有點納悶，節前不是已經討論清楚了嗎？
老大提了個新的設想，得到了很多人的擁護，所以原來的被推翻了。XY找紙畫給我看，其實變化不是很多，只是基於現有的一些現狀，老大又做了些調整。
原來的設想是，主幹作爲開發分支，存放的是新的需求變更和重大的缺陷，因而它是不穩定的，經過產品封版測試後，打出相對穩定的產品分支來，在產品分支上只做比較小的缺陷修改，針對該產品分支提出的重大的缺陷和變更將被推遲到新的主幹版本上。
現在的設想是：主幹是最新版本的產品分支（3.3)，在上面做缺陷處理，同時分出一個新的開發分支來（3.4dev），用來放置新的需求變更和重大的缺陷，在開發分支上的新的需求和變更開發完畢後，經過測試後，將差異的部分合併到主幹上，然後標記出3.4產品版本來，同時打出新的開發分支（3.5dev）來，並找到上一個版本（3.3）打出一個新的產品分支來維護。
從配置管理員的角度，新的做法其實比舊的做法複雜了，並且新的做法存在一下幾個缺點和侷限。
1 由於開發分支長期不同步到主幹上，所以合併的難度增大，主幹上修改的缺陷極有可能和新的缺陷/變更發生衝突；
2 對開發分支的封版測試並不意味着新的產品版本的誕生，因而合併完畢後，還要進行更多遍的測試。
3 不太適合多個產品版本同時開發，
4 產品規劃策略應該是儘量只維護最新的產品版本和開發版本，且這兩個版本由一個團隊來維護。
但是，當開發人員每天只面對的是一個產品版本的缺陷，並且需求變更少於缺陷的發生頻率時，這又是比較合適的。目前的技術中心產品即是屬於這種情況，在新的方法中，開發人員不用去同步日益發生的大量的缺陷到主幹，這會讓他們感覺到一種略帶虛無的滿足。
同領域建模的理論一樣，配置計劃沒有對此之分，只有合適不合適一說。先推行之後再說吧。