其實也不算什么秘密,基本上大型軟件開發(fā)都會遵循的流程.Windows的源代碼之龐大,是很難想象的,這么多的代碼及程序員,不可能同時在一份代碼基礎上工作,因此基本上會分成很多很多的小的branch(分支). 比如說IE有自己的branch, 這個branch可以自己產生特定的Windows build,只有IE的程序員才會修改這個branch中的代碼. IE的測試工作大部分也在這個branch中進行.
而周期性的,小的branch會向大的branch匯聚,最后集中在windows的branch從而產生正式的build,比如7000,7022之類. 這個周期可能是一/二周不等. 每次向上匯聚之前,比如IE這周新的修改想要匯聚到windows,IE組會進行一些必要的測試以確定這次匯聚是安全的,以保證上面branch的代碼質量.
那么為什么說7000要比7022好很多呢?因為在產生7000這個build之前,所有下面的小branch會有一段時間的lockdown(鎖定),這段時間會進行很全面的測試,以保證最后匯聚上去的代碼的質量.這種測試要比平時例行匯聚時的測試要詳細很多.
并且,當所有子branch匯聚完成后,整個windows還會以最終匯聚的結果產生的build進行一個相當長的時間的測試,如果有問題就直接在匯聚版本里面直接修復,而不是通過子branch來修了.
一直到所有重要的問題全部在匯聚版本中修復了,才會最終發(fā)布對外的版本,也就是大家看到的7000版本.
而7022版本只不過是平時例行匯聚當中產生的一個普通build,只能作為內部測試用,從7000到7022期間發(fā)生的眾多修改很有可能產生原來沒有的問題,所以質量上而言7000絕對好于7022.
我自己7022也用了好幾周了,現在在用7031,每個版本都有些改動可以體會到,但是無論如何還是覺得7000最穩(wěn)定,沒有讓人感覺特別不舒服的問題. 我是工作需要所以才用新的版本,大家沒必要的話還是等RC吧,也快了.
而周期性的,小的branch會向大的branch匯聚,最后集中在windows的branch從而產生正式的build,比如7000,7022之類. 這個周期可能是一/二周不等. 每次向上匯聚之前,比如IE這周新的修改想要匯聚到windows,IE組會進行一些必要的測試以確定這次匯聚是安全的,以保證上面branch的代碼質量.
那么為什么說7000要比7022好很多呢?因為在產生7000這個build之前,所有下面的小branch會有一段時間的lockdown(鎖定),這段時間會進行很全面的測試,以保證最后匯聚上去的代碼的質量.這種測試要比平時例行匯聚時的測試要詳細很多.
并且,當所有子branch匯聚完成后,整個windows還會以最終匯聚的結果產生的build進行一個相當長的時間的測試,如果有問題就直接在匯聚版本里面直接修復,而不是通過子branch來修了.
一直到所有重要的問題全部在匯聚版本中修復了,才會最終發(fā)布對外的版本,也就是大家看到的7000版本.
而7022版本只不過是平時例行匯聚當中產生的一個普通build,只能作為內部測試用,從7000到7022期間發(fā)生的眾多修改很有可能產生原來沒有的問題,所以質量上而言7000絕對好于7022.
我自己7022也用了好幾周了,現在在用7031,每個版本都有些改動可以體會到,但是無論如何還是覺得7000最穩(wěn)定,沒有讓人感覺特別不舒服的問題. 我是工作需要所以才用新的版本,大家沒必要的話還是等RC吧,也快了.