[Development] Where and how does Qt define which platforms are supported?

Koehne Kai Kai.Koehne at digia.com
Fri Oct 25 09:49:47 CEST 2013

> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
> Behalf Of Thiago Macieira
> Sent: Friday, October 25, 2013 12:05 AM
> To: development at qt-project.org
> Subject: Re: [Development] Where and how does Qt define which platforms
> are supported?
> [...]
> At best, we can talk about what the trend is. For example, we can reasonably
> expect right now that Qt 5.2 will have QNX/BB10, Linux/X11, Windows, OS X,
> and Android as Tier 1, and iOS remains to be seen (it's its first release, after
> all). We can say that because we can see that people are working on those
> platforms. Similarly, we know of exactly one person working on FreeBSD, and
> we've seen a handful of patches for Solaris coming a couple of months ago --
> those platforms are trending to Tier 2. That's based on *reality*.

We had a more specific notion of 'platform' so far, which makes a big difference. E.g. for 5.0 we only listed following platforms as reference platforms:


Which was what is in the CI at that time. Does that mean we don't care about say compilation errors with msvc-2010-opengl ? Not at all, we would consider it even a release blocker, but we don't build with that platform all the time, so things might slip through.

What we'd offer to an end user could be:

Supported Platforms on Windows

Supported compilers are MSVC 2010, MSVC 2012 (all x86 and x86_64), MinGW-builds 4.7.2 (x86), and MinGW-builds 4.8.0 (x86).
Supported target platforms are Windows XP, Windows Vista, Windows 7, and Windows 8 (all 32 bit and 64 bit).

Qt is regularly tested with following compilers/configurations: Visual Studio 2010 Service Pack 1 x86 (ANGLE build), Visual Studio 2010 Service Pack 1 x64 (ANGLE build), Visual Studio 2012 Update 3 x86 (OpenGL build), Visual Studio 2012 Update 3 x86 (OpenGL build), MinGW-builds x32-4.8.0-release-posix-dwarf-rev2  (OpenGL build).

Or something similar. The latter (the 'reference platforms') is just a hint to the user what might be the most tested combination, not a binary 'supported' / 'not supported' matrix, and is more or less the list of combinations we build installers for.

I understood so far the latter list is called 'Reference platforms' (though there's some ambiguity whether it's the combinations we provide binary installers for, or the platforms in the CI system), the former one are all Tier 1 platforms.

Tier 2 would be e.g. Visual Studio 2008 (don't know actually, does anybody test?), gcc 4.7.2 from Mingw.org, Mingw-builds x86 64 bit  ... I'm not sure whether that should belong into any 'official' documentation though, maybe in a separate wiki page?
Tier 3 ... well, I can't think of anything to put in there for Windows :)

> Anyway, here's an alternative:
> We modify the "reference platform" definition to be more flexible and
> change over time. That means the project starts requiring work on some
> platforms and will dedicate resources to them even if the original team
> disappears.
> The Linux kernel does that: once a driver is upgraded from "drivers/staging"
> (a.k.a. TAINT_CRAP) into the regular ones, it gets maintained even if the
> original maintainer disappears. It gets fixed if there are changes elsewhere
> that break it.
> GCC does that for its platforms too: once it's supported, it remains supported
> for at least two releases. If the team behind a platform disappears, the
> platform is mentioned in the release notes saying "it will be removed in the
> next if no one steps up to maintain it".

I think the original promise was that we never drop Reference Platforms below Tier 1. Anyhow, I agree that might be too strict ... I'm not sure anybody still cares about mingw-builds 4.7.2 32bit with SJLJ in 2016 :) So +1 for weakening this to a 2 releases promise.

> So, for Qt, we could adapt our reference platforms over time to match the
> actual work happening. We're not stupid: we'll only accept platforms into the
> reference category if we see that there is actually interest in them and a
> reasonable community of people who can  maintain it. We're not going to
> accept code dumps (neither the kernel nor GCC do it -- see Linus's latest rant
> against Linaro drivers).
> If we do adopt this categorisation, then I'd like to modify the tier system so
> we don't end up with four levels. Unless people actually like:

I think we should have only:
+ Reference Platforms
+ Supported Platforms
+ Platforms Reportedly Working



More information about the Development mailing list