[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: QT_DEPRECATED_BEFORE/KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 considered harmful
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2019-10-24 16:22:07
Message-ID: 4183425.OgyPujdiqX () klux
[Download RAW message or body]

Am Donnerstag, 24. Oktober 2019, 17:40:51 CEST schrieb laurent Montel:
> Le jeudi 24 octobre 2019, 16:53:04 CEST Friedrich W. H. Kossebau a écrit :
> > Am Donnerstag, 24. Oktober 2019, 16:32:32 CEST schrieb Volker Krause:
> > > For master however this is less of an issue, as you say we actively port
> > > that away from deprecated methods (and at least regarding KF5, we
> > > ideally
> > > do that even before deprecating a method).

Ideally != reality. And often one introduces new API at the same time as 
deprecating old API. This at least is what I saw when doing all the patches 
for the deprecated API of KF modules to use ECMGenerateExportHeader, many 
"@deprecated Since x.y, use foo()" pointed to foo() with "@since x.y".

> > I see it still as an issue for new-comers but also oldies who want to fix
> > a
> > bug in some application, for that checkout the master branch and first
> > will
> > have to fight a broken build, due to newer deprecated API.
> 
> As volker wrote we will fix code before to deprecate an api (or decrease
> KF_DISABLE_DEPRECATED_BEFORE_AND_AT on specific apps which can't build
> easily without deprecated methods).

"We"=? Who is going around to check all existing software if some API of a KF 
module got deprecated? KDE CI also does not catch this instantly, as it will 
not be triggered to rebuild dependent projects if there was a change to a 
library. So those will only fail once there was another commit.

Even more, for all actively worked on projects things will instantly break on 
CI once a new API deprecation has entered stage and is spilled into the 
Dependencies build. And people will get used to builds failing even more 
("possibly just a new deprecation, why do they get in my way, no time to 
care").

> > IMHO also git master should always be buildable, and not have planned
> > breakage-due-to-new-deprecated-API.
> 
> The problem is if we must wait that people fix deprecated method without
> forcing a little, for sure nobody will work on it.
> 
> I can see a lot of kde apps which is not maintains (see kdegames for
> example). So nobody will change KF_DISABLE_DEPRECATED_BEFORE_AND_AT

The alternative proposed for unmaintained^Wcommunity-maintained software would 
then be: have them break now already? And hope someone will fix it, instead of 
just discarding it because, broken build and no-one caring? While it otherwise 
would still be fine?

> It's too bad as it's the first time that we have a method for removing
> deprecated methods before next big version... I remember when we switched
> between kde2/kde3/kde4/kde5 we made porting when we decided to switch to new
> version, so we didn"t test porting on current branch as we can do now.
> 
> Today we can remove deprecated method during ~ 1.5 years. But if we wait
> that each dev decided to increase KF_DISABLE_DEPRECATED_BEFORE_AND_AT we
> will arrive at the same situation as kde5 switching.

Why do you think that the compiler-warning approach does not work? If you look 
closely, now and then people (besides you) do go after code having deprecation 
warnings. It's just that they do not jump on them immediately.
Compare e.g. the warnings for use-override. People by the time went and 
adapted the code, thanks to the warnings.

Well, I made my point and hopefully made people aware of the issue.
At the end, it's up to the respective project maintainers/release coordinators 
what they want. The projects I (co-)maintain do what I recommended here :)

And with this notice done, I also have a place to point to for everyone who 
might come after me and the introduction of ECMGenerateExportHeader and any 
potential issues due to the IMHO misuse of KF_DISABLE_DEPRECATED_BEFORE_AND_AT 
:)

So again, here is what I recommend to use, to disable API deprecated first up 
to a given version, and see warnings for any other API deprecated only in 
newer versions:
--- 8< ---
add_definitions(
    -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x05c000
    -DKF_DEPRECATED_WARNINGS_SINCE=0x060000 # default would be: ^
    -DQT_DISABLE_DEPRECATED_BEFORE=0x050900
    -DQT_DEPRECATED_WARNINGS_SINCE=0x060000 # default would be: ^
)
--- 8< ---

Cheers
Friedrich


[prev in list] [next in list] [prev in thread] [next in thread]