[Development] Deprecation/removal model going into Qt 6

[Manuel Bergler]

Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler <
kevin.kofler at chello.at>:

> Volker Hilsheimer wrote:
> > The overall goal here is to make sure that we don’t have to carry poorly
> > designed architecture or APIs around with us throughout the Qt 6 series,
> > and as long as we care about binary and source compatibility within a
> > major series, doing what we can for Qt 6.0 (and doing it right) is the
> > only option we have.
> >
> > Perhaps we can care less about those compatilbiity promises; I personally
> > think the "big bang every 7 years” is not giving us nearly as much as it
> > costs; a continuous flow of carefully managed changes to either would
> > perhaps make it rather easier for developers to follow along, and remove
> > those big, painful porting headaches (unless you didn’t follow the Qt
> > releases, in which case it’s just as bad as it is today).
>
> But the problem for developers is NOT the 5.x releases that do not break
> the
> API. Those are great! The problem is those n.0 releases that DO break the
> API. And the solution there would be to just stop doing this kind of
> releases. Changes such as deprecating or incompatibly rewriting a data
> structure as central as QList (as seems to be already consensus for Qt 6)
> are just a major disservice to developers. ABI breaks such as the QString
> SSO (that also seems to be already consensus for Qt 6) are also
> unnecessary
> and probably also counterproductive in some use cases. And switching the
> build system for Qt itself to CMake, while still supporting both CMake and
> QMake for user code (as Qt 5 with its QMake-based build system already
> does), can be done without breaking source nor binary compatibility.
>
> Your proposal to break ABI at every 6.x minor release would be an absolute
> nightmare for distributors. It would no longer be possible to upgrade
> stable
> releases of a distribution like Fedora to a new Qt as is frequently done
> now. Rolling-release distros would also suffer, having to go through a
> coordinated mass transition each time. And third-party PPAs upgrading Qt
> for
> a stable distribution would also become harder to offer (because they
> would
> have to rebuild ALL Qt-using packages, not just those (ab)using private
> APIs). I do not see how this would be an improvement over the current
> situation at all.
>
>         Kevin Kofler
>
>

There are at least two ways Qt and/or distributors could deal with ABI
incompatible changes in minor releases of Qt 6. First of all, Qt itself
could make use of inline namespaces to ship several version of the same
classes in the same binary while keeping source compatibility. And if Qt
doesn't want to go that route because of maintenance overhead then the
distributors themselves could decide not to ship just a single version of
Qt, but rather have multiple versions side-by-side using the custom
namespace and library infix option already provided by Qt.

That said, I'm in favor of allowing ABI (and in my opinion even API)
breaking changes in minor releases, since that allows to evolve APIs
continuously instead of only once every major release. Right now, even
though the API and ABI are stable, I have never seen an update to a new
minor version of Qt5 that did not require source changes due to changed
behavior, so fixing a few calls that no longer compile doesn't increase the
cost of updating all that much. As a matter of fact, fixing source
incompatibilities is in my experience much easier than figuring out why
behavior has changed, since I don't even have a starting point where to
look in the latter case.

Best
Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190602/021cdc23/attachment.html>