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至今

固定的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.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。

第四位版本號確立地位

激進的步伐引發的問題當然也讓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。

事實證明這樣做挺好, 并且該模式也一直延續到今天(這是后話, 在下篇文章中詳述)。

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則開啟合并窗口, 進行下一個新的版本的開發。如此周而復始。

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

[1]: 其實對Linux項目真正誕生的日期，存在不同的看法：有人認為是1991年8月25日Linus在Usenet上發表的關于Linux系統的帖子開始，也有人認為應從v0.0.2版本公開發布之日算起。可以看看Linus本人的看法。

總結

以上是生活随笔為你收集整理的linux 开发组织模式,Linux内核发布模式与开发组织模式(1)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。