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' _______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
