Qt 5.6LTS vs 5.7+

[Duncan]

René J.V. Bertin posted on Sun, 04 Sep 2016 02:11:41 +0200 as excerpted:

> That seems like it doesn't really fit with Qt's principle of backwards
> API and ABI compatibility, and the design based on platform architecture
> plugins (QPA). Code built and linked against Qt 5.6 is supposed to run
> with Qt 5.7 (as long as it doesn't use private APIs). Your argument
> would make more sense if the evolving Wayland support interfered with
> support for the other QPAs. But it shouldn't; if you don't use Wayland
> you shouldn't be affected by changes in Wayland support at all.

I meant more or less what they've done with qtquick(1), where it was 
deprecated and made optional in favor of the newer versions of the API in 
qtdeclarative.  The older module can still be built to support things 
still using that API/ABI, but they're not putting any more work into it 
except for the very minimal necessary to keep it working with the rest of 
qt.

And distros running current kde have already dropped qtquick.  Certainly 
gentoo has, tho I suppose it's still around for some of the slower more 
sta(b)le/glacial ones, altho there's also the question of whether they 
even adopted qt5/kde5 in the first place, being so glacial and plasma5 
only relatively recently becoming reasonably stable.

The wayland code in the LTS 5.6 could be similarly deprecated and made 
optional, except that little using wayland, at least qt on wayland and 
thus that code, is actually deployed yet, so it'd be much more of a case 
of "if early qt-wayland code dies in the forest and nobody was around to 
ever see it live in the first place, did it ever live or die at all" type 
thing.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman