[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