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
- Deprecation is not removal
- But we need new API to mark "deprecated, but not to be removed API"