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

[Maurice Kalinowski]

> -----Original Message-----
> From: Sérgio Martins <iamsergio at gmail.com>
> Sent: Dienstag, 23. März 2021 20:40
> To: Maurice Kalinowski <Maurice.Kalinowski at qt.io>
> Cc: Matthew Woehlke <mwoehlke.floss at gmail.com>; Volker Hilsheimer
> <volker.hilsheimer at qt.io>; Qt Interest <interest at qt-project.org>
> Subject: Re: [Interest] The willy-nilly deletion of convenience, methods
> 
> On Tue, Mar 23, 2021 at 6:23 PM Maurice Kalinowski
> <Maurice.Kalinowski at qt.io> wrote:
> >
> > >
> > > 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.
> 
> That's not a fair comparison.

And I don't think it is fair to now merge a separate discussion into this. Generally, this thread contains way too many topics at once to be able to keep a streamlined discussion.


> After Qt 5.0 was released in 2012 we still saw several Qt 4 bugfix releases (up
> until 2015).
> With the situation now, we're in a limbo, there's no 6.2 and there's no Qt5
> open-source bugfix releases.
> 

I can see this concern from your side, totally. But as mentioned above, I commented on the part whether removals have happened between Qt 4 and 5. And they did, in worse fashion.

Maurice