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