# 測試和發布
一旦源代碼tarball已經從穩定的發布分支產生,發布過程公共部分便已經開始。但是在tarball進入公開之前,必須經過少量開發者的確認,通常需要三位或者更多。確認不僅僅是檢測發布的明顯缺陷;理想情況下,開發者應該下載tarball,在干凈的系統上構建并安裝,運行回歸測試包[Chapter?8, *管理志愿者*](# "Chapter?8.?管理志愿者")的(見[the section called “自動測試”](# "自動測試")),然后執行一些手工測試。假如通過了這些檢查以及項目的其他的發布檢查列表條件,開發者可能需要使用GnuPG([http://www.gnupg.org/](http://www.gnupg.org/))、PGP([http://www.pgpi.org/](http://www.pgpi.org/))或其他可以產生PGP兼容簽名的程序為tarball作出數字簽名。
大多數項目中,開發者僅僅使用個人的數字簽名,而不是許多開發者(有一小部分,擔不是大多數)希望使用的項目共享密鑰。簽名的開發者越多,經過的測試也就越多,一個關心安全的用戶也就越可能找到一個到達該tarball的數字信任路徑。
一經確認,發布版本(所有的tarballs、zip文件以及其他需要分發的格式)就應當放置到項目的下載區,并伴有數字簽名,以及MD5/SHA1校驗(see[http://en.wikipedia.org/wiki/Cryptographic_hash_function](http://en.wikipedia.org/wiki/Cryptographic_hash_function))。有許多做這些工作的標準。一種方法是為每個發布包提供一個對應的數字簽名,以及一個校驗文件。例如,如果發布包是`scanley-2.5.0.tar.gz`,在同一目錄的`scanley-2.5.0.tar.gz.asc`包含了這個tarball的數字簽名,另一個文件`scanley-2.5.0.tar.gz.md5`則包含了MD5校驗,也可以有另外一個`scanley-2.5.0.tar.gz.sha1`文件,包含SHA1校驗。另一種方法是收集所有發布包的簽名到一個單獨的文件`scanley-2.5.0.sigs`;校驗文件與之類似。
具體怎樣做并不重要。只要保持簡單的模式,描述清楚,并在每次發布保持一致即可。所有簽名和校驗的目的是為了用戶校驗自己的拷貝未經惡意修改。用戶會在自己的電腦上運行這些代碼—所以如果代碼被篡改,攻擊者可以立刻擁有到達所有數據的后門。本章后面的[the section called “安全發布”](# "安全發布")有更詳細的介紹。
### 候選發布
對于包含許多變更的發布版本,許多項目會首先推出*發布候選*,例如`scanley-2.5.0`之前的`scanley-2.5.0-beta1`。候選的目的讓代碼在發布之前接受更廣泛的測試。如果發現了問題,可以在發布分支修正,并推出新的發布候選(`scanley-2.5.0-beta2`)。這個周期會持續到不能發現不可接受的bug為止,最后的發布候選成為正式發布版本—也就是說最后的候選發布和正式發布的唯一區別只是版本號碼的修飾詞。
在大多數其他方面,候選發布一定要與正式發布保持相同的待遇。*alpha*、*beta*或*rc*修飾足以警告保守的用戶等待真正的發布,而候選發布的聲明郵件也必須指出他們的目的是征求反饋。除此以外,應該對候選發布提供與正式發布相同的關注。畢竟,你希望人們使用候選版本,因為暴露是發現bug的最佳方法,而且也因為你永遠無法獲知哪個候選會最終成為正式版本。
### 宣告發布
宣告發布很像宣布其他事件,一定要采用在[Chapter?6, *交流*](# "Chapter?6.?交流")的[the section called “公開性”](# "公開性")中描述的程序。當然,對于發布要額外注意一些事情。
每當你提供下載發布tarball的URL時,一定要確保給出MD5/SHA校驗和數字簽名文件的鏈接。因為宣告會出現在許多論壇里(郵件列表,新聞頁等),這意味著人們會從許多地方獲取到校驗信息,這可以給關心安全的用戶額外的保證,證明了校驗本身沒有被篡改。反復提供數字簽名的鏈接并不會使其更安全,但是會讓人們(尤其是與項目比較疏遠的人)感受到項目對于安全的重視。
在宣告郵件和新聞頁中,不應該僅僅報告關于發布的宣傳信息,而應該包含CHANGES文件中相關的部分,這樣人們就能夠看到自己是否有興趣去升級。這對于發布候選和最終發布同樣重要;bug修正的出現和新特性的引入會吸引人們嘗試候選版本。
最后,不要忘記感謝項目團隊、測試人員以及所有花時間發起bug報告的人。不要單獨提出某人的名字,除非某人承擔了大量的工作,其價值被項目的每個人所認可。小心坐上信用貶值的索道(見[Chapter?8, *管理志愿者*](# "Chapter?8.?管理志愿者")的[the section called “榮譽”](# "榮譽"))。
- 前言
- 為什么寫這本書?
- 誰應該讀本書?
- 資料來源
- 致謝
- 免責聲明
- 1. 介紹
- 歷史
- 現狀
- 2. 起步
- 從你擁有的開始
- 選擇許可證并應用
- 設置風格
- 通告
- 3. 技術基礎設施
- 一個項目需要什么
- 郵件列表
- 版本控制
- Bug跟蹤
- IRC / 實時聊天系統
- RSS供稿
- Wikis
- 網站
- 4. 社會和政治的基礎架構
- 慈善獨裁者
- 共識為基礎的民主(Consensus-based Democracy)
- 寫下所有的內容
- 5. 金錢
- 參與的類型
- 長期雇傭
- 作為一些個體出現,而不是一個整體
- 公開你的動機
- 錢不能讓你可愛
- 契約
- 資助非編程活動
- 市場營銷
- 6. 交流
- 人如其文
- 避免常見的陷阱
- 刺兒頭
- 處理成長
- Bug跟蹤系統中無對話
- 公開性
- 7. 打包、發布和日常開發
- 版本號
- 發布分支
- 穩定發布版本
- 打包
- 測試和發布
- 維護多發布線
- 發布和日常開發
- 8. 管理志愿者
- 從志愿者中獲取最多
- 像分擔技術任務一樣分擔管理任務
- 轉化
- 提交者
- 榮譽
- 分叉
- 9. 許可證,版權和專利
- 術語
- 許可證的方面
- GPL和許可證兼容性
- 選擇一個許可證
- 版權分配和所有權
- 雙許可證模式
- 專利
- 深入資源
- A. 自由版本控制系統
- B. 自由Bug跟蹤系統
- C. 為什么我要關注車棚的顏色?
- D. 報告bug的樣例指導
- E. 版權