On Mon, Sep 05, 2022 at 05:15:45PM +0000, Marc Mutz wrote: > [...] > We have the tools (QT_REMOVED_SINCE + Ivan's work on > -disable-deprecated-until) to have a user-configurable, rolling BC window > now We should use these tools to avoid accumulating too much technical > [...] > That said, sometimes it's just simpler to do the API change together with > the rest. I wouldn't worry too much about the effect this has on users of > Qt APIs: Function argument widening is SC,
I currently fail to understand why all this work needs to have user-visible consequences *at all* before 7.0 - especially, but not limited, to the now apparently planned incoming stream of source-incompatible changes including related deprecations starting to hard-hit users from 6.8 on. What would have been wrong with starting with #ifdef I_AM_WORKING_ON_IT using qsizetyp_ = qsizetype; #else using qsizetyp_ = int; #endif then have the people working on it (and only those, plus perhaps potential early adopters) define the macro locally, "port" int to qsizetyp_, and when everyone is happy with the scope and the implication ofthe change, at 7.0 time, globally replace qsizetyp_ by qsizetype ? Why is all this done as operation at an "open heart" instead of having a "staging" and "production" setup? Andre' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
