[Development] A monologue about platforms in the Qt world
giuseppe.dangelo at kdab.com
Mon May 6 14:01:16 CEST 2019
On 02/05/2019 13:48, Tony Sarajärvi wrote:
> What's a supported platform?
> It means that The Qt Company gives you support if you stumble upon a problem with that distro
I don't agree on "The Qt Company gives you support" part. That's part of
whatever commercial support agreement one gets from TQC; the "supported
platform" definition (if any) should apply to the Qt Project, not to TQC.
> and the Qt release promised to work on that.
This is more like it. This promise should come from the "supported
platforms" documentation pages, e.g.
It's however totally unclear at this point what "supported platform"
means for the Qt Project. I've got a personal interpretation of this,
but I don't know if it's codified somewhere. (E.g.: I consider a FTBFS
on a supported platform a P1 and a release blocker).
Maybe it needs to be made clear, in Qt's policies as well as the
> But what’s unclear is what it actually means that Qt should work on that platform. Does it mean that the binaries we distribute should work on that? Or does it mean that Qt builds on it if you take the sources and compile them yourself?
True, it's somewaht confusing for the end user. But IMHO I would not mix
the two. To me, supported means that you can build from sources and run
In other words, to me, it does not mean that a platform is supported iff
there is a binary build of Qt available for that platform. Or, it does
not mean that a platform is supported iff such binary builds "work".
This is one of the most asked questions we’ve had here. A good example
is openSUSE 42.3 where examples don’t compile if you take our binary
release and try to work with that. But if you would compile Qt on that
distro, then it would work. (see
https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the
details). What do you think it means? Is one or the other answers wrong
As a consequence of my position above: to me it means that openSUSE *is*
supported (it's Linux/X11), but not by the binary builds.
> Lifespan of distros
> This is something we should have thought more about, but didn't. Perhaps still don't. Let's take Qt 5.12 as a good example here. Qt 5.12.0 was released on the 6th Dec 2018. It has a promised lifespan to at least the end of 2021. With us actually going development and testing before the actual release, we need to have the environment which we work on working at least 6 months before we release. Now that RHEL 7.4 was such an environment which was available then. Already released July 2017 and having an EOL (end of life) August 2019. Perfect! But the problem is our Qt 5.12.2, .3, .4, .5 releases. Should we be doing releases with a distro that isn't even supported by RedHat themselves? And there's the big question #1!
> Because of ignorance we didn't think about this when we documented things. We just blindly say that Qt 5.12 supports RHEL 7.4, because that's what we have in the CI! Yeah, but are we really supporting it in 2021, when RedHat themselves have pulled the plug on it over 2 years before that? Could we just update to the latest RHEL after all? Especially since we didn't use RHEL 7.4 to begin with, but our own distro as we modified the original RHEL?
That's another area where this is mixing two levels of "support". Qt
5.12 will be supported (by the _Qt Project_) until 2021. At least to me,
the support for the binary builds can change at any time during this
time frame, as the two supports are not tied to each other.
My 2 c,
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
More information about the Development