For Ubuntu LTS releases, I don’t think the LTS on release day is particularly more stable than other releases. Users that value stability will typically wait a while before upgrading. This is why I brought up delaying the marking of a release as LTS a bit. But I don’t think that is actually the standard way to do it.
Part of the reason for an LTS is for an animation studio to be able to start and finish a project in the same version. It’s not necessarily about having the least amount of bugs (though that option exists by waiting to upgrade), but also preserving backwards compatibility and not breaking the project files.
For example Unity still has 2017 LTS releases, which probably are not significantly more stable than 2018 LTS by now. Rather some games were developed with that version and the game developers in turn just want to release minor bugfixes of their games, not rewrite a lot.
I also think it’s important to understand that we have some flexibility in how much time we spend on this. There are certain types of bugfixes that we’d always want to backport (e.g. security or data loss issues), but for the most part “important bugfixes” is a flexible definition. It’s definitely not the intent to backport every bugfix, and likely in the second year the amount of backported fixes will be significantly smaller than the first.
If there is a big demand to backport more bugfixes (or even other types of backwards compatible improvements), we can find funding for that or get interested parties to contribute. We’re not making a promise here that if a bug for an LTS version is reported to the tracker, that we will actually investigate it. It should meet our standard for “important bugfix”.