# 維護多發布線 大多數成熟的項目都平行的維護多個發布線。例如，1.0.0發布后，該發布線會繼續微小發布1.0.1，1.0.2等等，直到項目明確的決定終止這條線。請注意，僅僅因為發布了1.1.0不足以終止1.0.x線。例如，一些用戶會制定某類政策，永遠不升級到較新的次要或主要版本的第一個發布—他們希望其他人能將bug試驗出來，例如1.1.0，那么就等待1.1.1。這不一定是自私（請牢記，他們也放棄了bug修正和新特性）；僅僅是出于某些原因，他們必須在升級上非常小心。因此，假設項目在發布1.1.0之前發現1.0.3中有一個重大bug，如果只是將bug修正納入到1.1.0，而告知所有的1.0.x用戶必須升級到1.1.0，其結果將會非常惡劣。為什么不同時發布1.1.0和1.0.4，這樣大家都能高興吧？ 待1.1.x線圓滿后，你可以宣布1.0.x進入了*生命結束（end of life，EOL）*。這一步必須正式宣告。宣告可以是獨立的，也可以作為1.1.x發布宣告的一部分；可是這樣做時，用戶必須能夠知道老的開發線正在被關閉，這樣他們可以根據情況決定是否升級。 一些項目設置了保證對于前一發布線作出支持的窗口時間。在開源環境中，“支持”意味著接受針對該線的bug報告，并在發現重大bug后發布維護版本。另外一些項目并沒有給出預定義的時間，而是根據報告的bug數量判斷還在使用較舊發布線的用戶。當低于某個百分比時，就可以宣布發布線的結束并停止對它的支持。 對于每個發布，請確保在bug跟蹤系統中有*目標版本*或*目標里程碑*，這樣人們可以根據正確的發布填寫bug。當然也不要忘記為最新的開發源代碼提供叫做“開發”或“最新”的目標，因為總有些人—不僅僅是活躍的開發者—通常會在官方發布的最前沿。 ### 安全發布 對于安全bug的處理請參考[Chapter?6, *交流*](# "Chapter?6.?交流")[the section called “聲明安全漏洞”](# "聲明安全漏洞")，但是對于安全發布有許多特殊的細節需要討論。 一個*安全發布*是一個專門關閉安全漏洞的發布。修正bug的代碼在發布之前不能公布于眾，也就是說在發布日之前代碼不能提交到版本庫，也意味著在公開之前代碼不能經過公共測試。很明顯，開發者可以自己檢查這個修正，并在私下里測試發布，但是無法進行廣泛的真實世界測試。 因為缺乏測試，所以安全發布必須是在現有發布基礎之上，只附加了安全bug的修正，沒有*其他變更*的發布。這是因為未經測試的變更越多，越有可能導致新的bug，甚至是新的安全bug！這種保守也是對管理員的一種友好，他們將要部署安全修正，但是他們的部署策略傾向于不在同一時間部署任何其他變更。 作出安全發布有時有些小的詭計。例如，項目可能工作于發布1.1.3，對于1.1.2的一些bug修正已經公開聲明，此時出現了安全報告。很自然，開發者在完成修正前不能討論安全問題，他們必須繼續討論，好像1.1.3還會按照計劃推出一樣。但是當1.1.3實際上到來時，與1.1.2的區別只有安全補丁，而所有其他的修正都會進入1.1.4（當然，現在*也會*包含安全修正，以后所有的版本也會一直包含）。 你也可以為現有的版本號碼添加一個額外的部分，以說明它只包含安全變更。例如，人們能夠知道1.1.2.1是針對1.1.2的一個安全發布，所有更高的發布（1.1.3，1.2.0等）會包含相同的安全修正。對于了解內情的人，這個系統可以傳遞許多信息。在另一方面，那些不能緊跟項目的人，當大多數時間看到的是3部分的發布號碼，偶爾看到4部分的號碼會感到混亂。我見過的大多數項目會選擇一致性，使用常規的下個號碼作為安全發布，即使它意味著計劃中的發布前進一個版本。