apoenitz at t-online.de
Mon Sep 12 20:04:44 CEST 2022
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;
> using qsizetyp_ = int;
> 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?
More information about the Development