如何開始一個新的開源項目(4)

　　頂 翻譯的不錯哦!

　　運營郵件列表的另外一個重要環節是對其進行積極地關注。對于用戶或開發者來說，沒有什么比自己被忽略更加令人沮喪了。如果你設置了一個郵件列表，花一些時間關注它，并 為那些提問的人作出答復。這是圍繞一個項目培育出開發者社區的最佳手段。讓一個郵件列表達到像樣的活躍度是一件比較費時的事，然而這是值得的。為有意向作出貢獻的人提供建議、建議人們在適當的時候提交成果(不要讓你的郵件列表變成bug追蹤工具!)、并且利用你從郵件列表中獲得的反饋來提升文檔的質量。

　　Nix

　　翻譯于 8天前

　　0人頂

　　頂 翻譯的不錯哦!

　　使用版本號

　　開放源代碼項目的一個常見的錯誤是忽視使用版本號。版本號對項目的長期穩定和維護時相當重要的。CSS Lint首次發布時沒時使用版本號，我很快就意識到錯誤。當有bug提交時，我不知道人們是否正在使用最新的版本，因為沒有辦法告訴用戶代碼是何時發布的，雖然提交的bug已經修復但用戶無從知曉。

　　Nix

　　翻譯于 8天前

　　0人頂

　　頂 翻譯的不錯哦!

　　將每個發布的版本用官方的版本號來標記，當有人提交bug時，你可以詢問他們使用的版本并檢查bug是否已經修補。這大大縮短了我花在報告bug 上的時間因為我可以馬上知道用戶是否在使用最新版本。

　　Nix

　　翻譯于 8天前

　　0人頂

　　頂 翻譯的不錯哦!

　　除非你的項目以前有過使用并已經通過審核， 否則以0.1.0位啟動版本號并遞增每個后續發布的版本。在 With CSS Lint中我們增加了第二個數字在作為計劃版本號，因此，0.2.0便是第二個計劃版本號，0.3.0是第三個以此類推。如果我們為了修補bug而需要發布一個介于兩個計劃版本之間的版本，我們需要增加第三個數字。因此在第二個計劃版本0.2.0之后的非計劃釋出本版號就為0.2.2.

　　不要誤解。這里并沒有什么規則來規定在一個項目中如何增加版本號，盡管這里有些值得參考的東西 Apache APR Versioning and Semantic Versioning. 我只是挑出來一些并遵循罷了。

　　除了對項目跟蹤的幫助，版本號當然還可以為你的項目做一些其他的事情。

　　TX

　　翻譯于 7天前

　　0人頂

　　頂 翻譯的不錯哦!

　　源碼控制中的標記版本

　　當你決定要發布一個新版本時，應用源碼控制標記來標注此版本的代碼狀態。當我們開始在CSS Lint中使用版本號，我也就開始這么做了。開始我沒考慮那么多，直到有一次我忘了給一個發布版添加標記，但是發現某位開發者提交的bug卻是針對那個特定標記的。這說明開發者們更傾向于檢出特定版本的代碼。

　　TX

　　翻譯于 7天前

　　0人頂

　　頂 翻譯的不錯哦!

　　要讓標記和版本號的綁定關系更明確，就把版本號直接包含在標記名稱中。在CSS Lint中，我們的標記都使用“v0.9.9”這種格式。這樣可以讓每個人都能夠很容易地通過標記名稱來識別其含義 — 包括你自己，因為你也將能夠更好地跟蹤每次版本發布的改動。

　　TX

　　翻譯于 7天前

　　0人頂

　　頂 翻譯的不錯哦!

　　變更日志

　　版本管理還有一個好處就是能夠生成變更日志。不管是對最終用戶和貢獻者，變更日志都是溝通版本差異時的重要依據。版本標記和源碼控制有一個附加好處，你能基于這些標記自動生成變更日志。CSS Lint的構建系統能夠在每次發布是自動生成一個包含提交信息及其貢獻者的變更日志。這樣變更日志就不僅只是一個代碼變更記錄，也是社區貢獻值的記錄。

　　TX

　　翻譯于 7天前

　　0人頂

　　頂 翻譯的不錯哦!

　　可用宣告

　　每當項目發布一個新版本時，都應該在某處發布宣告。不論是在你的博客或郵件列表或是在兩者上都發布，正式宣告項目新版本已經可用是非常重要的。這份宣告應該包括項目代碼的主要改動及其貢獻者。對貢獻者工作的認同是對他們的最大鼓勵，能從貢獻代碼中獲得更多的認同感他們就更有動力做更多的貢獻。所以給予那些耗費無數精力在你的項目中的開發者以最大的贊揚吧。

　　TX

　　翻譯于 8天前

　　0人頂

　　頂 翻譯的不錯哦!

　　管理代碼貢獻

　　萬事俱備，下一步就是解決如何接受代碼貢獻。 你的貢獻模型是非常規范還是很隨意，取決于你的喜好和目標。對應個人項目，可能不需要什么規范的貢獻流程。開發者指南應該說明合并代碼到倉庫的必要條件，一個提交先要滿足這些條件才會被接受。對于更大的項目，應該要有更多規范的策略。