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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
