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
