Release cycle zh TW
ASF使用常見的C#版本號碼，帶有4個數字，格式為A.B.C.D。 總是會固定特定的版本，並指向它組建的固定原始碼（附隨發布檔案）。 只要我們的代管服務供應商（GitHub）可以無限期保留它們，我們不打算刪除任何以前發布的版本，因此，您可以安全還原至任一個先前發布的版本，無需自行保留備份。
就一般的ASF版本號碼而言，我們會在最後3個有效數字⸺B.C.D上盡量遵照「主版號.次版號.修訂號」的版本格式語意化版本。 這三個數字與ASF程式碼直接相關。 最高有效數字A代表改動超出ASF代碼庫本身，通常會直接影響程式的基本架構。
作為一個專案，ASF的目標是或多或少在每個月發布一次功能版本，以增加數字C來表示。 為了使這些發布成為可能，我們專門為進階使用者提供了較小型的預覽版本，它們作為較小的改動里程碑，只要在上個預覽版本以來，具有足夠的改動就夠了。 最後，如果一個最新預覽版被確認足夠穩定和成熟，且與之前的穩定版本相比，沒有已知需要更正的嚴重問題，它將被升級成新的穩定版本，並開始下一個版本的每月週期。
雖然我們會盡量保證我們的預覽版本也相對穩定，但仍需注意，在任何生產環境中使用預覽版時應謹慎評估。 預覽版本可能含有嚴重錯誤或遭遇功能損毀，這也是我們這樣發布它們的原因：避免穩定版本出現這類情形，以此來提供可靠的軟體。 若您不願接受使用不穩定軟體所帶來的高風險，請不要使用我們的預覽版組建，並始終使用我們的最新穩定版組建，這才更適合大多數使用者。
依據週期中的更新數量，通常會有一個C版本的變更（從上個穩定版本），且每個預覽版都會依需要使D增加。 但是，當引入更大範圍的改動，特別是破壞性改動時，發布週期可能會提升至（或轉換到）B甚至是A的更改⸺這種轉換代表當前的發布週期可能比平時更不穩定，應更加仔細地測試。 請注意，語意化版本號碼的更改只與前一個發布的穩定版有關，我們不會追蹤同一週期內各個預覽版間的版本號碼，也就是說，版本1.0.1.2可能會擁有版本1.0.1.1中不存在的新功能，只要之前標示的穩定版屬於1.0.0.X系列。 同樣地，特別是當我們仍在決定引入的新功能，或類似功能的最終形式時，在同一週期內的兩個預覽版之間，也可能存在重大的破壞性改動。
| 版本號碼更改 | 語意化版本 | 更改的範例 |
|---|---|---|
| A | 更改.NET執行環境的主要版本、更改基本架構、超出ASF代碼庫本身的重大改動、可能會吃掉您的貓的東西 | |
| B | 主版號 | 更改.NET執行環境的次要版本、ASF代碼庫本身的重大改動、超出次要分類的主要程式碼編輯 |
| C | 次版號 | 新的每月週期，通常會引入新的功能、指令、設定屬性，或其他不會破壞現有設定的改動 |
| D | 修訂號 | 當前週期內的新預覽版本（由更高位數字表示），修復現有穩定版本的關鍵錯誤，不會引入不必要的程式碼改動 |
請注意，新引入的功能或改動可能會在一段時間後才被記錄（例如在Wiki上），因為文件通常是在該功能的最終程式碼完成後才編寫的（以節省我們每次決定修改該功能時，重寫寫到一半的檔案的時間）。 由於預覽版可能包含尚在編寫中未完成的程式碼，因此文件可能會在開發的下個階段中才編寫。 這件事情也同樣適用於一般的更新日誌，它可能要經過一段時間後才能用於指定的預覽版。 因此，若您決定使用預覽版，請隨時查看ASF內部的Commit。 當然，只有預覽版才有可能缺少文件⸺每個穩定版都必須在發布時擁有完整的更新日誌及Wiki上的文件。
將兩個版本進行比較的詳細更新日誌始終會在GitHub上：透過Commit及程式碼變更。 在發布中，我們傾向於只記錄我們認為上個穩定版與當前版本間的重要改動。 如此簡明的更新日誌不會是完整的，所以若您想查看兩個版本間產生的所有改動（例如升級相依套件），請查看GitHub紀錄比較。
ASF專案由持續整合程序提供支援。 每個組建版本都應該可被重現，因此若您取得指定版本的原始碼（包含於發布頁面），並自行編譯，應會得到與我們編譯完成的二進制檔案的結果相同。 只要系統還正常運作，我們通常避免自行編譯發布，已發布的二進制檔案是直接來自於我們的持續整合程序。
