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

[Jason McDonald]

Greetings once more.

Recently I've been doing some testing of the new cmake-based configure on
Linux. (It would be awesome if someone can do the same for other platforms.)

Perhaps naively, I started out by running configure with each command-line
flag listed by the old version of "configure -help", expecting the new
configure to be a drop-in replacement.

Naturally for something so new, I found a few regressions (many thanks to
the build system guys for responding to these issues so quickly) and a
couple of features of the old configure that were already broken (perhaps
evidence that those features are unused and could be retired).

A couple of the bugs I filed were about configure features that went away
after being supported for more than ten years.  Another relates to
PostgreSQL support on OpenSuSE, which worked fine for Qt4 and Qt5 but is
broken for Qt6, apparently due to a long-standing bug in cmake (or a bug in
OpenSuSE depending on your point of view).

For the C++ bits of Qt, we have long-established and well-understood
policies for source- and binary-compatibility and for deprecating features
in a way that telegraphs our intentions well in advance of functionality
disappearing.  I can't find any equivalent policies for the other parts of
Qt.

So, what I want to know is:

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?

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?

Cheers,
--
Dr. Jason McDonald
(macadder on FreeNode)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20201112/4d5bc490/attachment.html>