QtCS2024 Deprecate

Do we have a problem with our deperecations?

Follow up on Peppe, Andre' and others discussing SC/BC and the impact of deprecations on users, typically by way of breaking compatibility. Volker Krause and Kai Köhne each explored this in some detail on Thursday. Alex Blasche has prepared a presentation to help get this going.

Dsicussion notes:

- Note : Deprecation is not a removal

+ Counterpointpoint: It will happen, at least when there's a new major version

- deprecation vs removal: should deprecated methods not removed?

So far we always removed everything in a major release

- Proposal: Prune more often and earlier

+ Counterpoint: You still run into the same issue just in smaller sizes; people might even be more concerned about updating

+

- Maybe it's a good idea that people are forced to touch code?

+

- Statement: There are real world examples of people not updating to Qt, putting old Qt into a container; if they ever update, they might reevaluate and chose against Qt

- Stability of API was a selling point (even across decades)

- couple of points:

+ uptick of deprecations in 5.15 to prepare for architectural changes in Qt 6

+ removal is the big issue, not deprecation itself

+ Should we really do sweep in Qt 7? Decide on a granular base?

- current marcros are not up to making a distinction between deprecation and removal - do we need more macros to make that distinction

- sliding window /overlap is important for porting

+ new API added earlier

+ deprecation warning only triggers 5 versions after new API

+ claim: nobody would go from 6.0 to 7.0; can do cleanup/porting while upgrading minor versions

+ deprecations are meant to help people migrate to the next major version - get 5.15 warning-free, then transition to 6 is/should be easy

+ fine grained deprecation control is helpful

- challenging the severity of paper cuts – rewrite forcing deprecation are worse => things actually got better

- some API is a maintenance nightmare, we really want to remove them

- each deprecation decision is currently only done by very few people, who might not realize the impact

- 5 to 6 was easy, but still had to do quite a few changes => many projects have no one to work on non-critical work

- two levels of deprecation markers:

+ for which version of Qt should they get warning, no work if not enabled

+ QT_REMOVE_SINCE: configurable option to remove old cruft, needs to be selected

+ macro to completely remove old API, should only be used by new projects

+ we could keep sliding window forever in theory, but can't maintain everything

- do decision on what to keep for 7.0

+ must not be done late

+ has to be done earlier, opt-in vs opt-out

+ need a new macro right now, if we still use the the same strategy as being done for the 6 to 7 transition

- other projects are understaffed, but so are we

- challenge that many of the deprecation are actually broken / that deprecation was actually always necessary

- can't always do search & replace to fix stuff ( in the context of pos / positio)

- we need a way to warn ourselves to fix Qt

- completely hiding from documentation is bad

- how "forever" should "forever" be ?

-Implementation detail: QT_REMOVED_IN(7) could be used for things that really should go, current deprecations that

- What should we do if we want to change our mind from "keep forever => remove completely"

+ "forever" should only be based on some rationale, so can be reevaluated

- People might rely on "deprecated, but keep forever" even more than on non-marked API

- Put more work into being transparent

Summary

1. Deprecation is not removal
2. But we need new API to mark "deprecated, but not to be removed API"