> On 5 Feb 2020, at 16:31, Edward Welbourne <[email protected]> wrote: > > Shawn Rutledge (5 February 2020 14:14) >> So I’m strongly in favor of continuing to do deprecations as long as >> possible. A deprecation is not something that can break existing >> functionality, so it’s no real risk as long as we’re sure we really >> want to deprecate it. > > A deprecation can break existing builds, for those who enable > warnings-are-errors.
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. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
