It seems that in Canonical have taken into account many of the comments made not only by the community, but also by developers because a few days ago, through mailing lists they disclosed that have made the decision to make a change in the process to prepare intermediate LTS versions of Ubuntu (for example, 20.04.1, 20.04.2, 20.04.3, etc.), with the aim of improving the quality of the versions at the expense of meeting exact deadlines.
If the previous interim versions were formed in strict accordance with the planned plan, the quality and integrity of testing of all fixes will now be prioritized.
The changes were adopted taking into account the experience of several past incidents, as a result of which, due to the addition of a fix at the last minute and lack of time for verification, regressive changes or incomplete solutions of the problem arose in the version.
In an attempt to improve our processes and the quality of Spot release LTS images, starting with 20.04.3 (in August) we will be trying a slightly safer approach. Basically the main noticeable change is that now we will follow the SRU procedures even for any release blockers that we found during the one-off release week. This means that, in addition to some very exceptional cases, each correction (even for a blocker) will have to follow the same verification, regression analysis process and aging period, in which case, if an error is found in the post candidate images we will simply delay the point release until the correction is verified, aged and only then posted on updates.
Delaying the release of a point is unfortunate, but it is better than reducing our
Quality standards.
With that, they basically mention that as of Ubuntu 20.04.3 August update, any bug fixes categorized as launch crash made within a week before scheduled launch It will change the launch time, which will allow not to press the correction in a hurry, but to thoroughly test and verify everything.
In other words, if an error is found on builds that have release candidate status, the release will now be delayed until all revisions for the fix are completed.
We already had some cases where our last minute corrections sped up under time pressure, they were not tested thoroughly enough and were introduced regressions (or, equally annoying, seemed to be only partial arrangements). As quality is the most important aspect of any Ubuntu version, we want to make sure that users get the best experience from our spot release images.
To adapt to this change and ensure that the largest number of release blockers are found as soon as possible, we will also change the proposal of the series daily image is compiled 2 weeks prior to release (so week before the candidate images are planned for the first release).
Previously, we kept the daily images enabled for proposals up to a week before launch (only disabling them for when launch candidates are built), mainly as a legacy from the old days when proposed as a everything was updated as part of the process. This does not 'have has already been done for years (as it is no longer safe), so leave proposal in the newspapers makes less sense than in the past.
For early detection of issues blocking release, it was also decided to increase the freeze time for daily builds from one week to two weeks prior to release, i.e. before the first release candidate is released, there will be an additional week to test the frozen daily build.
Finally, It is also worth noting that it was announced that the Ubuntu 21.04 base was frozen from the introduction of new functions (Feature Freeze) and the focus was changed to finalize the already integrated innovations, identifying and eliminating errors.
If you want to know more about it, you can consult the following link.