Linux内核发布模式与开发组织模式

Linux内核社区经历20多年的发展，逐渐形成了一套完善的开发模式。作为想要加入社区进行开发的人来说，当然必须熟悉下这套模式啦，其中最重要的两点是：

• 内核发布模式
• 内核开发组织模式

本文将对第一点进行讲述, 第二点在下一篇中讲述。(没耐心看完整篇文章的的朋友,直接看本文总结)

内核发布模式

追溯Linux内核版本号发展沿革，可知其经历了三个阶段，这分别为

v1.0以前时期
v1.0至v2.6时期
v2.6至今

v1.0以前时期

从Linus于1991年10月5日正式发布v0.0.2开始[1], 到1994年3月14日发布v1.0, 这中间经历了若干个版本的发布。此时尚未形成模式。

v1.0至v2.6时期

这一段时期，Linux用的是著名的奇数号开发版本,偶数号稳定版本模式。版本号模式为(以下引用文字来自维基百科):

A.B.C

• A大幅度转变的内核。这是很少发生变化，只有当发生重大变化的代码和核心发生才会发生。在历史上曾改变两次的内核：1994年的1.0及1996年的2.0。
• B是指一些重大修改的内核。
• C是指轻微修订的内核。这个数字当有安全补丁,bug修复,新的功能或驱动程序,内核便会有变化。

其中，当B为奇数，标明这是一个开发版本; 当B为偶数，标明这是一个稳定版本。其运转模式如下:

新的特性或功能总是基于稳定版本开发, 如果新增的代码太过于庞大与激进, Linus就会另开一个比当前版本号大1的奇数版本号,是为开发版本。新特性或新功能代码被引入该开发版本, 如果该版本被认为方向不对, 则干脆就直接抛弃该版本内核; 相反, 如果该版本稳定下来, 则考虑把它 1) 合并为当前稳定版本。2) 另开一个分支,变成一个新的偶数版本号。

这样粗粒度的版本号模式，意味着相当长的发布周期: 一般是2-3年一个稳定版本, 如图1所示: 从v2.0 到 v2.2，从v2.2 到 v2.4, 从v2.4 到 v2.6, 都经历了2-3年不等的时间。

图1: v1.0 - v2.6 发布时间

如此长的发布间隔时间，意味着：一个新的硬件上市，买家需要花几年的时间来等待内核的支持，这是无法忍受的；而这也迫使各个发行版本商从开发版本中向后移植新的特性，这导致了发行版间内核的分歧越来越大, 这是人们所讨厌的。这是这个版本号模式抛弃的重要原因。

v2.6至今

1. 固定的2.6版本号

   进入v2.6时期，Linux内核核心开发者决定不再创建2.7分支, 而继续在2.6分支上进行新功能的开发。核心开发者Greg Kroah-Hartman写了一篇文章对此作了一些解释。大概原因是: 在2.6版本释出前, Linus的主内核分支(mainline)进行了长达数个月的特性冻结, 不再接受新特性代码。这样, 进入Linus主内核分支的代码都首先经过另一个核心开发者Andrew Morton)维护的-mm分支(将在下篇文章中讲述)的测试; 而且其它子系统维护者也会把他们的分支代码先在Andrew Morton的-mm分支中进行测试, 之后代码才支进入Linus的mainline。可以说-mm分支取代了v2.6时代之前奇数号分支这一新功能试验场的作用。这样的模式稳定了不少, 新功能也得以更快速被吸收入mainline内核中。于是, 前面所述的奇开发偶稳定, 长周期的版本号模式被抛弃了。 2.6版本号固定下来, 内核沿着2.6.X的递增版本号进行发布。

2. 第四位版本号偶然登场: 2.6.X.Y

   在这样的模式引导下, 内核确实加快了开发步伐: 从2003年12月8日到2004年12月24日这一年时间内, 内核发布了从v2.6.0到v2.6.10这11个版本。这样激进的步伐还是招致了不少内核开发者的意见, 他们认为每个v2.6.X版本都是伪装的开发版本, 因为还是有很多不稳定的PATCH被引进了。这其间一个事件也反映了这一点, 并且让内核的版本号又多了一位: 在Linus发布v2.6.8的当天, NFS代码中就发现了一个亟待解决的重大错误，而此时显然不会为了修改这一个错误而再发布一个新的版本，于是，Linus发布了v2.6.8.1。

3. 第四位版本号确立地位

   激进的步伐引发的问题当然也让Linus对这一模式进行了思考。于是, 在发布v2.6.11当天，Linus发了封邮件, 宣布要采用一种新的模式: 重回奇偶版本模式, 但这种模式较之2.6前的奇偶模式更小粒度。2.6.<奇> 与 2.6.<偶>都是稳定版本, 只不过, 对奇数版本来说, 对新功能代码的接受更加宽容, 但它必须被密切关注, 以确保它们不会出现大问题; 对偶数版本, 则更加谨慎, 只接受一些被认为是稳定的补丁。

   Linus这种表面看都是稳定版本, 内里则行奇偶之别的做法并未得到开发者们的认同。在那封邮件里, 出现了少有的很长的讨论, 大家认为出现问题的原因还是因为测试太少。虽然, 补丁在进入Linus的mainline前有经过前面所说的-mm分支的测试; 在Linus每发布一个版本前的rc预览版本(将在下篇文章中讲述)也经过用户的测试, 但实际问题是这两个途径都没发挥它们的作用: -mm分支因为是新代码的试验场, 不太稳定,有时连编译都失败, 少有开发者愿意在该分支上测试; 而rc版本在用户看来不是正式的官方发布版, 也少有人愿意测试它们。

   既然测试太少问题难解, 那不妨以补救方式来对正式版本进行修正!

   有人提出了这个建议, 并把前面所说的v2.6.8引入的四位版本号拿来使用: 每当释出一个v2.6.X版本, 如果有重要的bugfix或安全补丁, 则移植到v2.6.X上, 并释出新的bugfix版本: v2.6.X.Y。Linus本人起初不看好, 觉得这是一项没有多少成就感, 吃力不讨好的工作, 没有人愿意做。但Greg Kroah-Hartman站出来, 并建立新的一个-stable分支来做这件事。他进行这种尝试的第一个版本就是v2.6.11.1。

   事实证明这样做挺好, 并且该模式也一直延续到今天(这是后话, 在下篇文章中详述)。

4. 3.0时代, 换汤不换药

   在2011年7月21日,Linus释出了原本应为v2.6.40的新版本v3.0, Linus在邮件中解释说, 新的3.0版本号,只是为了庆祝Linux20周年庆,同时丢弃掉笨重的2.6.X数字系统。

   可以说,3.0时代的版本号模式并没有改变, 只不过是把2.6改成了3, 并且从0开始版本号计数而已, 它的象征意味更浓些。

总结

从v2.6开始的版本号模式, 缩短了版本周期(大概2-3个月一个版本), 改变了之前以奇偶数分开发,稳定版的漫长周期模式。 每个版本都有若干个(5-7个)候选版本(rc, release candidate)的形式发布, 作为预览版。 一般来说,只有第一个rc接受新特性或新功能代码, 此rc就是俗称的合并窗口, 当开发者认为该版本已经解决了上一个版本的一些regression问题, 内核足够稳定了, 就会发布新版本。新的版本释出后会交到Greg K-H维护的-stable分支进行维护, 接受bugfix或安全补丁。而Linus则开启合并窗口, 进行下一个新的版本的开发。如此周而复始。

* * * * * * 全文完 * * * * * *