[Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

[Thiago Macieira]

On Wednesday, 24 March 2021 09:58:50 PDT André Pönitz wrote:
> > The exact opposite is the correct thing:
> >  - deprecation messages while compiling the source code are correct
> >  - messages to the mailing list are not sufficient
> 
> Sorry, this assumes that "user" people constantly compile their application
> against Qt dev branch to notice. That is obviously not the case. And once it
> is already merged or even released it's practically to late.

If you meant that "too late to reverse the deprecation", then yes. It could 
eventually be reversed, if the need was great (we did un-deprecate QPointer, 
after all), but the vast majority of deprecations are there for good. If you 
want to know about deprecations early enough to have a say in whether they 
should be deprecated or not in the first place, you need to participate in 
development.

If you meant "too late to port", then I disagree and this is what I meant. 
When finally making progress, you get the warnings before you have to modify 
your code. The point is that people can make progress updating the Qt and 
other components in their applications without having to worry about replacing 
deprecated APIs. This is the time to deal with the inevitable 
incompatibilities that will arise. Once that is done and you have a working 
application (even if not certified or released), you go and fix the warnings.

> I am /not/ saying it is wrong to _also_ put deprecation warnings into the
> code, but most deprecations I've seen lately would have deserved a somewhat
> broader discussion than (exaggerated...) two people agreeing on a random
> change on gerrit. Asking actual users would be a good start from my
> perspective.

The usual reaction is defensive: "I'm using this, so it must be good and 
you'll pry it from my cold dead hands!" That's why I said that polling users 
is usually not a good solution, even if it were statistically representative.

Polling source code, on the other hand, could be. "Oh, crap, just about every 
other application we checked uses this thing!" That may not change the actual 
decision on deprecation, but it may advise us on how long the replacement API 
must have been available for, how long we must keep compatibility for (see 
QLocale::country()), whether we need to educate developers (see the whole 
"derive from QThread" discussion).

When was the last time we had as part of the Qt release procedure rebuild all 
of KDE and figure out what we had broken? I remember this for 4.4, maybe 4.5.

> Also, even the "code only" way deprecation process is unsatisfactory at
> times: We've had cases where there no hints what the "better" way would be.
> In some cases, alternatives appeared only at the time where the previous
> functions was deprecated/removed, in some cases the suggested replacement
> was ugly and/or error prone, in some cases there was simply no alternative
> at all.

I agree. And I think we've learned from this. The feedback from the Qt Creator 
development team on exactly this issue is what led to the creation of the 
QT_DEPRECATED_VERSION_xxx macros. We even adopted as a policy that a 
replacement needed to be available for one LTS release before the warning 
could be emitted by default, but then the whole discussion on LTS happened 
too. And it doesn't help that 5.15 required a lot of deprecation *because* of 
6.0's development revealed it. At least I hope that those compatibility 
methods are still there in 6.0.

For the aforementioned QLocale::country() deprecation, I adopted a simple 
policy that its replacement must have been available for 2 years (4 releases) 
before the warning starts being emitted.

> > At that point, the decision has already been made. I am not discussing how
> > to make the decision on deprecation. That's not a vote either: we don't
> > remove things because we think no one uses them, with very few exceptions
> > (like QLinkedList). We remove things because they are badly named, have
> > flawed API or design, result in improper code, make progress impossible
> > otherwise, etc.
> A lot of that is highly subjective, and already the reasons you mentioned
> are broad enough that one can practically find a suitable excuse to
> deprecate anything.

That may be, but I sure hope it it isn't. I am specifically excluding the 
"willy-nilly deprecation" that was suggested, that we do things on a whim 
because we're evil and/or think no one is using something. That is NOT how we 
work.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering