Hi Tony, 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.
https://doc.qt.io/qt-5/supported-platforms.html
https://doc.qt.io/qt-5/linux.html
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 official docs?
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 Qt there.
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 here?
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.dang...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
