QtCS2024 Deprecate: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Mention V.K.'s talk.)
(added notes)
 
(One intermediate revision by one other user not shown)
Line 3: Line 3:


Follow up on [https://lists.qt-project.org/pipermail/development/2024-June/045429.html Peppe, Andre' and others] discussing SC/BC and the impact of [[deprecation]]s on users, typically by way of breaking [[Qt-Version-Compatibility|compatibility]].
Follow up on [https://lists.qt-project.org/pipermail/development/2024-June/045429.html Peppe, Andre' and others] discussing SC/BC and the impact of [[deprecation]]s on users, typically by way of breaking [[Qt-Version-Compatibility|compatibility]].
Volker Krause's talk on Thursday explored this in some detail.
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.
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"

Latest revision as of 12:34, 6 September 2024

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"