2 kirigami fixes for a point release

[Nate Graham]

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