[Development] Policy for backwards-compatibility of non-C++ assets

[Thiago Macieira]

On Wednesday, 11 November 2020 06:08:41 PST Jason McDonald wrote:
> 1. Are our customers entitled to expect that features of non-C++ parts of
> Qt won't disappear without first being flagged as deprecated, and
> documented as deprecated, for a reasonable period, in line with the policy
> for the Qt libraries?

I think we need to detail these per asset. For example, QML needs to have its 
own policy.

On the topic at hand:
* qmake functionality should keep working, so long as it's using public qmake 
   API. The difficulty here is that this is not documented, so people use a 
   number of internal things found in the CONFIG, QT_CONFIG variables and the 
   qtConfig() function.
* the configure command-line is not API and has always been subject to change. 
   We do not need to keep compatibility there across major versions. People 
   are expected to start their configure command-lines (or direct cmake lines) 
   from scratch.
* the functionality provided by the configuration should be retained, at least 
   for supported / regular use-cases. What this means is up to us.

> 2. If long-standing Qt functionality is broken by external vendors who
> can't agree on who should fix it, how hard am I entitled to push for our
> developers to try to work around the problem to keep the functionality
> working for our customers, versus giving up and just documenting the
> breakage in the Qt5 to Qt6 porting docs?

Again I think this is subjective. If the workaround on our side is reasonable 
or if we think it's really necessary, we should apply it. Otherwise, we can 
blame whomever we think the blame should fall on and document it.

I don't know what the extent of the issue of the PostgreSQL breakage you're 
describing is. If it prevents building the plugin at all and the problem is 
widespread, then we need to work around. If the problem is exclusive to 
OpenSUSE and/or only appears under certain conditions, we can document it and 
point to an bug report, so people add their voice asking for the proper fix. 
Though note we use OpenSUSE in our CI, so we may need to have the workaround 
ourselves!

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering