On 2020-02-13 00:42, Ben Cooksley wrote:
A better way of approaching this would be to freeze the Frameworks
version you are going to require API wise at an earlier point in the
Plasma development cycle. This would allow for a full Frameworks
release cycle to pass where bugs encountered during the lead up to the
Plasma release can be fixed.
This version of Frameworks would then be the one that Plasma hard depends on.
We do this; Plasma 5.18 has a minimum Frameworks dependency of 5.66. See
https://community.kde.org/Schedules/Plasma_5#Support_status_by_Release_Series
The problem here isn't so much API breaks but rather major bugs and UI
regressions. if a framework has a very visible bug or UI regression in
5.66 of the kind that we would really like to fix, but LTS distros
freeze on that version, then LTS users will be stuck with that issue
forever unless we make a frameworks point release or cajole distro
packagers to backport the fix.
Rolling release distro users will first see Plasma 5.18 with Frameworks
5.67, so if that frameworks version has a major bug or UI regression, it
will take a month for the fix to land in users' hands whereas if the
issue were in Plasma itself, we could fix it immediately and users would
get the fix in a week (the first point release is one week after the .0
release).
My point is that the schedules just don't really match up if we want to
present a polished finished product and continue to fix bugs for the
lifetime of an LTS release.
Nate
