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