[Development] Deprecation/removal model going into Qt 6

[Kevin Kofler]

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