[Development] QtCS: Long Term Release discussion

Thiago Macieira thiago.macieira at intel.com
Wed Jun 17 09:02:07 CEST 2015


On Wednesday 17 June 2015 08:35:58 André Somers wrote:
> Thiago Macieira schreef op 16-6-2015 om 22:49:
> > Last year's notes[1]
> > 
> > Qt 5.5 will be the last release to support:
> >       *  GCC 4.6
> >       *  OS X 10.7
> >       *  Windows Vista
> >       *  WIndows Embedded Compact 7
> >       *  QNX 6.5
> >       *  Qt WebKit, Qt Script, Qt Quick 1
> 
> Ok, I understand that support for these has to go at one point, though
> I'm not feeling too happy that that happens to be in a point release.
>  From my point of view, it breaks the compatibility promise of Qt. But I
> guess that's all water under the bridge, and there is nothing that can
> be done about it. We just can't maintain it any more I understand
> (especialy WebKit).

We've been through this time and time again. Let me repeat once more and never 
again:

There's no breakage of the compatibility promise. The code for those modules 
is not getting deleted from the Internet. You can still build the existing 
versions with newer versions of Qt and that should continue working. The 
number of changes required to keep Qt Quick 1 and QtScript running in the past 
4 minor releases supports this statement; QtWebKit never depended on Qt 
private API in the first place.

What's more, this is our BKM for deprecating modules. We've done that twice 
already: once for Qt Script Classic and once for QtAssistant ADP.

> > Qt 5.5 would be ideal - but we'd need to support the old Qt CI system for
> > longer. So we're targetting that *Qt 5.6* will be the first LTS release.
> 
> And that I don't understand, as it is exactly 5.6 that is no longer
> supporting a list of platforms, compilers and tecnologies that people
> actually rely on, right? So it seems to me, that making 5.6 LTS is one
> release too late. For instance, if one is relying on Quick 1 like we
> are, how are we supposed to stay on a supported platform? And no,
> porting to Quick 2 isn't an option. Not as long as we can't print the
> contents of our scene like we can with our Quick 1 based reporting
> engine by simply rendering pages (sections of the scene) to a QPrinter.

You're right. The problem is manpower.

So our hands are tied and we're making a less-than-ideal decision considering 
the technical aspects.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list