似乎在 規範已考慮到許多評論 不僅是由社區，而且還由開發人員製作的，因為幾天前， 通過郵件列表 知道 已經決定更改準備中間LTS版本的過程 Ubuntu版本（例如20.04.1、20.04.2、20.04.3等），目的是以犧牲確切的截止日期為代價來提高版本的質量。
如果以前的臨時版本嚴格按照計劃的計劃形成，則將優先考慮所有修補程序的測試質量和完整性。
考慮到過去幾起事件的發生，採用了這些更改， 結果，由於在最後一刻添加了修復程序，並且缺少足夠的驗證時間，因此該發行版中出現了對該問題進行遞歸更改或不完整的修復程序。
為了改善我們的流程和質量 現貨發布LTS圖像，從20.04.3（八月）開始，我們將 嘗試一種更安全的方法。 基本上是主要的明顯變化 就是現在我們將遵循SRU程序，即使對於任何 我們在現貨發行週內發現的釋放阻滯劑。 這 意味著，除了一些非常特殊的情況外，每次更正（即使對於 阻止者）將必須遵循相同的驗證，回歸 分析過程和老化週期（在這種情況下，如果發現錯誤） 在候選圖片中，我們將僅延遲該點 釋放，直到更正通過驗證，老化，然後才發佈到 更新。
不幸的是，延遲釋放一個點很可惜，但這總比減少我們的任務要好。
質量標準。
有了這個， 他們基本上提到 從Ubuntu 20.04.3 August更新開始， 歸類為啟動崩潰的所有錯誤修復 在預定發射前一周內完成 它將更改啟動時間，從而不必急著按下更正內容，而是可以徹底測試和驗證所有內容。
換句話說，如果發現錯誤 在具有候選發布狀態的版本中， 現在，該版本將延遲到該修補程序的所有修訂完成為止。
我們已經有一些情況，我們的最後一刻改正加快了速度 在時間壓力下，它們沒有經過充分的測試，因此被引入 回歸（或者同樣令人討厭，似乎只是局部的 安排）。 由於質量是所有Ubuntu版本中最重要的方面， 我們希望確保用戶從我們的網站上獲得最佳體驗 現貨發布圖像。
為適應此更改並確保釋放阻止程序的最大數量 盡快找到，我們還將更改提案 系列的每日圖片在發布前2週進行了編譯（因此 計劃在第一版候選圖像之前的一周）。
以前，我們將每天的提案圖片保留為一周 啟動前（僅在啟動候選時禁用它們 建），主要是作為提議時的舊時代的遺產 一切都作為該過程的一部分進行了更新。 這沒有 已經做了很多年了（因為它已經不再安全了），所以請假 報紙上的提議比過去沒有意義。
為了及早發現阻止發行的問題，還決定將每日構建的凍結時間從發行前的一周增加到發行前的兩週，即，在發布第一個候選發行版之前，將有額外的一周的時間每天測試凍結建造。
最後， 還值得注意的是，它宣布Ubuntu 21.04 base已凍結 從引入新功能（功能凍結）開始，重點已轉移到最終確定已經集成的創新中，從而識別並消除錯誤。
如果您想進一步了解它， 你可以諮詢 以下鏈接。