On Wednesday, 5 February 2020 08:03:45 PST Shawn Rutledge wrote: > It defeats the purpose of deprecation to do that before you are ready. It’s > something to be done later, to verify that you really have gotten rid of > all uses of the old API. “Later” should not be as long a time as it has > been in the past (as in deprecating something only in documentation in 5.0, > and then waiting until 5.14 to deal with the consequences); but it also IMO > should not be treated as a P0 blocker issue hanging over our heads the > instant after deprecating something, to go and rewrite all uses in all > modules. It’s technical debt though.
Deprecation should be done preferably at least one release after the replacement API became available. If that's not possible, in the same release. Deprecating without a replacement should only be done if there will be no replacement or if the API is actually harmful. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
