On Wed, Sep 07, 2022 at 06:38:30PM +0200, A. Pönitz wrote: > 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?
Could anyone involved in the decision making that resulted in the approach taken here please comment? Andre' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development