2 kirigami fixes for a point release

[Ben Cooksley]

On Sat, Feb 15, 2020 at 8:10 AM Nate Graham <nate at kde.org> wrote:
>
> 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.
>

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.

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.

>
> Nate

Regards,
Ben