2 kirigami fixes for a point release

[Nate Graham]

On 2020-02-15 11:55, Ben Cooksley wrote:
> My point above was that the version you decide to freeze on should
> only be the version you depend on during development.
> The version you depend on when you release will be the next release of
> Frameworks (so by freezing on 5.66 for development, it should have had
> a release-day dependency of 5.67)
> 
> The release of Plasma should then take place shortly after the
> Frameworks version you have a release-day dependency on.
> 
> You stagger it like this to ensure that developers are performing a
> full burn in of the Frameworks version for several weeks on their
> systems, and to ensure that all the problems they find end up in the
> Frameworks that users will have on their systems.

None of this makes a difference for distros that ship LTS Plasma don't 
ship newer Frameworks versions. No matter how much testing you do, some 
bugs in Frameworks will slip through and need to be fixed after the 
release. But the frameworks release cycle has no concept of the 
post-release bugfix like Apps and Plasma do; instead the expectation is 
that the distro will just ship a new Frameworks version in a month. This 
expectation does not match the reality for the distros that want to ship 
an LTS plasma version and do not ship newer Frameworks versions.


> As for the distributions that are refusing to update Frameworks, do
> you have a list of those distributions?
> If they're providing a poor experience to our users then we at the
> very least should ensure we steer people away from them.

Oh, you know, just some weird, unimportant little ones, like Debian, 
Ubuntu/Kubuntu, and openSUSE Leap. ;-) We should definitely make sure 
that our users don't use *those*; it's not like they're the big heavy 
hitters of the Linux world that are used in large numbers by 
corporations and shipped on hardware or anything. :)

Nate