Firefox的trunk、branch、Nightly版本和Release 版本的区别

mozilla/firefox的开发主要是这样的，
首先是有一个trunk，可以理解为主干，code name是seamonkey，不断的有新的代码加入，包括新的feature, bug fix等等，每天会从trunk上check out一次代码，做一个build，这个就是trunk的nightly build。
每次准备要出一个新版本的时候，会做一个branch，可以理解为分支，和trunk独立起来，这样在trunk上加入的新代码就不会影响branch的稳定。branch主要做bug fix和小的功能性的修改，branch加入代码的要求相对严格，除了得到review和super review外，还需要得到dirver的approve。aviary就是firefox 1.0的branch的code name,在release之前每天也会check out代码做一次build，这个是属于某个branch的nightly build。
branch中需要改的bug都改完后，mozilla.org的QA就会同意做最终的release（通常在最终release前会有几个release condidate，都是为了确保最终发布产品的质量)，会在branch上打一个tag，然后check out代码，做build，正式发布。
有一些branch，mozilla.org会决定长时间的维护，也就是在release了一个版本后，会在branch上继续加入一些重要的bug fix。比如mozilla1.0, 1.2, 1.4, 1.7以及firefox 1.0都是或者曾经是这样的branch。这样的branch即使在release以后仍然有代码加入，所以仍然会做属于这个branch的nightly build，然后在合适的时候发布minor release，比如firefox 1.0.1, 1.0.2等等。现在的所谓的firefox1.0.4其实就是aviary目前(真正的1.0.4发布前)的nightly build。
这些过程，看图最直观了:


你的1.0+的nightly实际上是trunk的nightly,在没有branch之前，版本就没有改，哪天1.1出了branch，你再取得1.1 branch上的nightly,就可能是1.1a或者1.1b了，再看trunk，可能就是1.1+的了。

说了这么多，也不知道说清楚没有。

猫头猪：mozilla/firefox的开发主要是这样的，
首先是有一个trunk，可以理解为主干，code name是seamonkey，不断的有新的代码加入，包括新的feature, bug fix等等，每天会从trunk上check out一次代码，做一个build，这个就是trunk的nightly build。
每次要出一个新版本的时候，会做一个branch，可以理解为分支，和trunk独立起来，这样在trunk上加入的新代码就不会影响branch的稳定。branch主要做bug fix和小的功能性的修改，branch加入代码的要求相对严格，除了得到review和super review外，还需要得到dirver的approve。avariy就是firefox 1.0的branch的code name,在release之前每天也会check out代码做一次build，这个是属于某个branch的nightly build。
branch中需要改的bug都改完后，mozilla.org的QA就会同意做最终的release（通常在最终release前会有一个release condidate，都是为了确保最终发布产品的质量)，会在branch上打一个tag，然后check out代码，做build，正式发布。
有一些branch，mozilla.org会决定长时间的维护，也就是在release了一个版本后，会在branch上继续加入一些重要的bug fix。比如mozilla1.0, 1.2, 1.4, 1.7以及firefox 1.0都是或者曾经是这样的branch。这样的branch即使在release以后仍然有代码加入，所以仍然会做属于这个branch的nightly build，然后在合适的时候发布minor release，比如firefox 1.0.1, 1.0.2等等。现在的所谓的firefox1.0.4其实就是aviary的nightly build。
这些过程，看图最直观了:


你的1.0+的nightly实际上是trunk的nightly,在没有branch之前，版本就没有改，哪天1.1出了branch，你再取得1.1 branch上的nightly,就可能是1.1a或者1.1b了，再看trunk，可能就是1.1+的了。

说了这么多，也不知道说清楚没有。回到原帖

总算彻底弄清楚怎么回事情了，这种方式两头都能照顾，还是挺不错的。

好解释，建议授精。:)

头有点大了......

这样的话如果发现一个BUG，到处的代码都要调整，路线是比较明确清晰，维护起来版本越多就越痛苦吧。

嗯，很好，知道了

白衣布道：头有点大了......

这样的话如果发现一个BUG，到处的代码都要调整，路线是比较明确清晰，维护起来版本越多就越痛苦吧。回到原帖

还行吧。

不是每个bug都需要进每个branch的，具体信息是在bugzilla上维护的。
如果有某个bug需要进入某个branch，会在bugzilla的flag项标上blocking <branchname> [?]，driver同意了就把问号改成[+]，否则改成[-]，有了patch以后会在patch上标注approval<branchname>?，driver同意也会改成approval+，然后就可以加入到这个branch。看个例子吧:
https://bugzilla.mozilla.org/show_bug.cgi?id=282270

需要长时间维护的branch并不多，现在也就只有mozilla1.7和firefox1.0两个。当然，如果有人志愿维护mozilla1.4，也会让你维护的，开源社区么，

其实大部分软件开发流程和版本维护都是这么做的，mozilla也没什么特别的地方，只是开放原码的软件你可以拿到中间过程的nightly build，封闭原码的你只能拿到release而已。

这个是版本控制的一些最基本的概念。软件开发的基本要素。。
linux下应该是用CVS。

我们现在开发用的事subversion..
版本控制还是蛮有意思的。。
尤其是 分支和合并 两个概念

长见识。

fygenius：这个是版本控制的一些最基本的概念。软件开发的基本要素。。
linux下应该是用CVS。

我们现在开发用的事subversion..
版本控制还是蛮有意思的。。
尤其是 分支和合并 两个概念回到原帖

subversion不错,比起CVS我更喜欢subversion. Madfox的source tree就是用subversion来维护的.

subversion是不错。但是使用范围毕竟还不是很广。。
很多软件只支持CVS,不支持 subversion,不过eclipse可以用插件支持subersion了.每次都用 TortoiseSVN来作为版本控制的客户端毕竟不方便
http://tortoisesvn.tigris.org/

问一下楼主：
driver 翻译成中文叫什么好？
release condidate? 是 release candidate 吧……

是不是可以理解为,trunk是最新的,最勇敢的小白鼠专用