> 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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
