[Development] On deprecating functions

[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.

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'