On Sonntag, 2. Juni 2019 10:20:51 CEST Manuel Bergler wrote: > Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler < > > kevin.kof...@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. > I have no problem with breaking ABI more often but allowing it in every minor releases probably goes to far. Perhaps every second LTS (every 3 years), might be better.
'Allan _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development