[Development] Deprecation/removal model going into Qt 6
Frederik.Gladhorn at qt.io
Mon Jul 1 17:22:34 CEST 2019
On søndag 2. juni 2019 11:50:35 CEST Volker Hilsheimer wrote:
> > On 1 Jun 2019, at 16:12, Alberto Mardegan <mardy at users.sourceforge.net>
> > wrote:
> > On 5/31/19 4:24 PM, Volker Hilsheimer wrote:
> >> Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with
> >> three years maintenance. We are not expecting lots of people to jump
> >> on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when
> >> an API was marked as deprecated makes perhaps not that much
> >> difference “in real time”.
> > Three years is not a lot of time when moving between major releases. It
> > would be nice if the last LTS release in a major release series were
> > supported for a longer time (5 years?).
> > Ciao,
> > Alberto
> How long did it take y’all to move from Qt 4.x to Qt 5.x?
> The move from Qt 2 to Qt 3, and from Qt 3 to Qt 4, is brought up as examples
> of bad experiences (but then let’s also consider how terrible Qt would be
> today if we would still have to drag Qt 2 or Qt 3 concepts around with us).
> But if the goal for Qt 6 is to be rather comparable to the Qt 4 to Qt 5,
> how bad would it be?
> Of course, milage will vary depending on the nature and size of your
> codebase, and I’m sure my colleagues in The Qt Company sales would be happy
> to discuss support options, when the time comes.
I don't think there's a conflict here: If we had frequent major version bumps,
I'd still expect some of these (one version of each major)? To be the LTS
version for that major, which will be supported for quite a long time.
We can give people ample time to move forward, while still creating new
And I think the smaller the time delta between major releases, the easier it
is to move forward.
> Development mailing list
> Development at qt-project.org
More information about the Development