週期性

每X個月釋出一個新功能版本。我們初步建議X = 6個月。

LTS版本將是N個功能版本中的一個。我們初步建議N = 4。

按照這些數字，一個新的LTS版本將每24個月釋出一次，並在接下來的24個月內獲得支援，直到下一個LTS版本。這與今天的每個功能版本18個月的錯誤修復週期略有相似。

預釋出版本

更頻繁的功能釋出意味著每次釋出中破壞性更改的數量更少。因此，預釋出版本（alpha和beta）的數量可以大大減少。在常規情況下，兩個alpha版本和一個beta版本可能就足夠了。釋出候選版本的數量，一如既往，取決於最終釋出前最後時刻修復的數量。

對開發週期的影響

更多的功能釋出可能意味著開發和釋出管理團隊面臨更大的壓力。這透過減少預釋出版本的數量在數量上得到緩解；並透過減少破壞性更改的數量（意味著更小的潛在破壞）在質量上得到緩解。較短的功能凍結期（從第一個beta版本到最終釋出）更容易接受。在功能凍結前匆忙新增功能的現象也應該大大減少。

對錯誤修復週期的影響

根據擬議的數字，對錯誤修復的影響應該最小。同時開放進行錯誤修復維護的分支數量將保持不變（直到2.x終止，然後是一個）。

對工作流程的影響

新功能的工作流程將相同：開發人員只會將它們提交到default分支。

錯誤修復的工作流程將略有更新：開發人員會將錯誤修復提交到當前的LTS分支（例如3.3），然後將它們合併到default。

如果某個非LTS版本需要一些關鍵修復，可以從當前LTS分支移植到非LTS分支，就像今天將修復從3.x移植到2.7一樣。

對社群的影響

重視穩定性的人可以只同步LTS版本，根據擬議的數字，這將提供相似的支援週期（無論是在持續時間還是穩定性方面）。

重視響應性和訪問新功能（不冒安裝alpha版本或Mercurial快照的風險）的人將從新的釋出週期中獲得比當前更大的價值。

希望貢獻新功能或改進的人將更有動力這樣做，因為他們知道自己的貢獻將更快地提供給普通使用者。此外，較短的功能凍結期使得與功能貢獻者互動變得不那麼繁瑣。