[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:       laurent Montel <montel () kde ! org>
Date:       2019-10-24 16:52:34
Message-ID: 6049170.IUyCgBKvl5 () linux-zym0
[Download RAW message or body]

Le jeudi 24 octobre 2019, 18:22:07 CEST Friedrich W. H. Kossebau a écrit :
> 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.

For example I rebuild all kde each week.
And I think that other guys do the same.
So perhaps CI will not catch at the moment.

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

Who told you that it will keep broken ?
If we show that it doesn't build we will fix it.
I don't see the problem.


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

See all apps compile log for example and you will see a lot of compile 
warnings.
I don't fix all compile warnings in pim*, I fixe when it breaks compile.

Until now we have some deprecated warning message in Qt or KF5 and nobody 
fixed them. So I am sure that people will not lose time to fix them.


After that if the kde policy is to use your proposition ok, I will not fight 
against it, it's just too bad that we don't use your 
KF_DISABLE_DEPRECATED_BEFORE_AND_AT for increase porting quality (I explain: 
porting until kf6 and not just porting when we will switch to kf6).

(After that I will continue to use 
KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 on pim* so I will not wait last 
time for porting deprecated method.)


Regards.

>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


-- 
Laurent Montel | laurent.montel@kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 
 www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent 
software solutions 


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