[Interest] The willy-nilly deletion of convenience, methods

[Maurice Kalinowski]

> 
> Not all deprecations are bad. However, I still maintain that *some* of the Qt
> 6 changes are problematic. Also, TBH, I think the real issue is less that Qt 6
> made changes, and more that Qt 5 support got pulled well before Qt 6 is
> viable for most folks. That didn't happen with Qt 4 → 5.
> 
> I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff that was
> immediately removed in Qt 5.0, although I may be wrong about that.
> 
[Maurice Kalinowski] 
There was, plenty of them, more than from Qt 5 to Qt 6.
And even more so, we had not the time to do deprecation warnings, like you can enable now when building against 5.15.
Hence, the migration should be (and according to user discussions is) much easier for this major release.

Another aspect I would like to reiterate is why not all modules are available with the initial 6.0 release.

For Qt 5.0 we tried to get everything over in one big go. The problem was that many of the features and behavior changes did not get fully executed through the leaf modules. That led to the situation that we couldn't do many modernizations afterwards again due to binary compatibility promises in the Qt 5 series. Thus, the approach was/is to have 6.0 with the set of most used modules.
From there get verification by users, that the changes have been in the right direction and broaden the module support then. As that allows to focus on bringing over modernization to those leaf modules, but also have dedicated time to modernize these as well.

From what we've seen on reviews on blogs/articles/tweets/... this approach works. Admittedly, with not everyone being able to migrate as of now. But I strongly believe that with 6.2 we will have a much better Qt compared to taking the same approach as with Qt 4->5, even at 5.2 times.

BR,
Maurice