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

[André Pönitz]

On Tue, Mar 23, 2021 at 05:09:51PM -0700, Thiago Macieira wrote:
> On Monday, 22 March 2021 14:55:04 PDT Roland Hughes wrote:
> > A deprecation message at compile time is __not__ a warning to the
> > installed base. This is especially true for things that were built with
> > earlier versions of Qt and are now just being recompiled with a much
> > later version.
> > 
> > A message in interest saying "Hey! We are about to nuke this, is anyone
> > actually using it?"
> 
> 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.

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.

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.

> The sample of developers in this mailing list is far too small. Any reply we 
> got from here would not be significative.

...

> Warnings posted here would not reach  the majority of the audience either.

Warnings put in the code do not reach anyone not involved with Qt development
_in time_.

> But creating warnings when you compile your code is a good way to let people 
> know that they have to take action at some time. No function can be removed 
> until the next major version, so you have until then to figure out.

[But removing whole modules is ok...]

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

Some of the contested deprecations were based on arguments along the lines
"it does not exist in plain C++, so it is a flaw in Qt to have it", some
where accepted on "makes user code nicer" - when the only solution for
user code to make it compile at all was to introduce(!) preprocessor use
around the affected code.

If these ara acceptable arguments in favour of deprecations one does not
even have to have any "rules".

Andre'