[Development] On deprecating functions

Christian Ehrlicher Ch.Ehrlicher at gmx.de
Tue Mar 5 06:56:50 CET 2019

Am 05.03.2019 um 00:37 schrieb André Pönitz:
> 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.
We could add a new define similar to QT_DISABLE_DEPRECATED_BEFORE - 
QT_DEPRECATED_WARNINGS_BEFORE which is by default initialized to the 
same value as QT_DISABLE_DEPRECATED_BEFORE but can be set to something 
else if needed.


More information about the Development mailing list