[Development] Policy for backwards-compatibility of non-C++ assets
thiago.macieira at intel.com
Wed Nov 11 18:28:35 CET 2020
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
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
* 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)
* 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
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
More information about the Development