[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

Bernhard Lindner private at bernhard-lindner.de
Thu Jun 6 09:42:40 CEST 2019


> The "mixed signal" here is that someone in an ivory tower decided to
> deprecate something but was not able to offer a viable alternative.
> 
> Either because there simply was none (in which case the deprecation was
> wrong, and should be undone) or because the work-around was too much hassle
> (in which case the deprecation was wrong, and should be un-done) or for some
> other reason that nobody cited so far.
> 
> As a matter of fact, some of the previous deprecations, e.g. the removal
> of qalgorithm, triggered re-implementing the deprecated functionality
> downstream, effectively shifting the burden of doing (or, rather,
> *keeping*) them once centrally to all users who need it decentrally.
> 
> All in all, this is devaluating the overall Qt offering.

I couldn't agree more.

Deprecating a component without (equal or better) replacement is an MCA in my book. And it
heavily damages Qt's reputation.

The criteria that allows to deprecate a component without proper replacement should be
EXTREMELY defensive.

-- 
Best Regards,
Bernhard Lindner



More information about the Development mailing list