似乎在 规范已考虑到许多评论 不仅是由社区，而且还由开发人员制作的，因为几天前， 通过邮件列表 知道 已经决定更改准备中间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已冻结 从引入新功能（功能冻结）开始，重点已转移到最终确定已经集成的创新中，从而识别并消除错误。
如果您想进一步了解它， 你可以咨询 以下链接。