[Development] Deprecation/removal model going into Qt 6

[Volker Hilsheimer]

> On 3 Jun 2019, at 13:34, Kevin Kofler <kevin.kofler at chello.at> wrote:
>>> I'd rather get fewer (or even no) new features than losing existing ones.
>> 
>> How is this even an argument? Qt will need to evolve and acquire
>> features to remain competitive. Again, development bandwidth is finite:
>> either the overall quality decreases or some things have to get dropped.
> 
> Qt has long reached a point where it can be considered complete. Its main 
> selling point is portability to many different platforms rather than some 
> specific feature. Additional features don't necessarily need to be in the 
> main Qt library, but can be in community-developed addons such as KDE 
> Frameworks or such as the many third-party Qt-based Free Software libraries 
> out there. (They can also be in Qt-Company-developed Qt Solutions if there 
> is manpower left for that.)
> 
> Qt has also become larger and larger over time (despite the removal of APIs 
> considered obsolete). Just compare the size of the Qt 3 tarball with the 
> size of the Qt 5 monolithic tarball. This is not the result of keeping old 
> APIs around, but of feature creep.
> 
> So I disagree with the assertion that Qt needs more features to remain 
> competitive.



I suppose the same can be said for Linux distros :)

But even if we say that Qt is feature complete: the platforms and technologies we sit on top of will continue to develop and change. For example, OpenGL will sooner or later disappear from macOS. NTFS has had symlinks and junctions, which Qt knows precious little about. HTTP/2 is a thing.

Some of the changes necessary to stay relevant on these platforms we can make without breaking APIs; some of them we can’t. For example, QFileInfo::isSymLink is a poor API given the file types on NTFS (shortcut files, ie. .lnk; junctions, which are like hard-links for directories; symlinks; files; directories). Of course, we can keep it around forever while introducing a more nuanced API, but the code that implements the old API is a mess to maintain as well, and will likely interfere with a clean and maintainable implementation of a better API.

In addition, sometimes we don’t get it right the first time. In fact, any strategy that is based on the assumption that “we get it perfectly right the first time so that we never have to change it” is bound to fail. I crafted the first version of QAccessible, and I wonder how many of you can be bothered with implementing your accessbility interfaces when you implement your custom widgets or QML controls. That ultimately affects real people, and if we have to break API or ABI to make it more likely that all UI elements are accessible, then let’s please do that.

It’s always a trade-off, and each case needs to be discussed. Nobody is recommending that we are mindlessly removing or changing things just because we can. But going the other extreme and saying "nothing must ever change because people will have to change their software” is not better.

Volker