On Mon, Mar 04, 2019 at 03:12:33PM -0800, Thiago Macieira wrote: > On Monday, 4 March 2019 13:48:25 PST André Pönitz wrote: > > The proposed model would effectively introduce another user-visible > > level including associated period of time between "alternative > > solution gets introducd" and "getting nagged about not using it" > > that is "hopefully" long enough, to cover "most interesting" > > (to be blunt: read: "including my") use case. > > I don't think we should deprecate things, much less warn about, until there's > a suitable example, except in few cases where the API was mis-designed and > has > no solution. That doesn't mean the solution needs to be a simple search-and- > replace, but it needs to exist. > > Does that change what you're proposing?
There's a difference in so far that I request a certain period of time (or rather, a span of Qt versions) both, old and new version, compile and do not cause a warning in a default Qt build. How long that period should be is left open to debate, proposal on the table is "one LTS cycle". One could think about shorter/longer times for more crucial/more cosmetical changes, but the minimum should allow people to upgrade from one LTS to the next without unusable intermediate states. Whether there's a simple search-and-replace is indeed secondary here, although I'd rather prefer user code to not get more complicated or verbose as result of the API "improvements". I, btw, also expect a default build of Qt to be (almost) free of warnings, which seems not to be the case today. Some of the deprecations apparently have been introduced without even bothering to fix one(!) version of Qt itself. Andre' _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
