Le jeudi 24 octobre 2019, 18:22:07 CEST Friedrich W. H. Kossebau a =E9crit :
> 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 =E9c=
rit :
> > > 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).
>=20
> Ideally !=3D 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 patch=
es
> for the deprecated API of KF modules to use ECMGenerateExportHeader, many
> "@deprecated Since x.y, use foo()" pointed to foo() with "@since x.y".
>=20
> > > 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.
> >=20
> > 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).
>=20
> "We"=3D? Who is going around to check all existing software if some API o=
f 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.

=46or 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.

>=20
> 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").
>=20
> > > IMHO also git master should always be buildable, and not have planned
> > > breakage-due-to-new-deprecated-API.
> >=20
> > The problem is if we must wait that people fix deprecated method without
> > forcing a little, for sure nobody will work on it.
> >=20
> > 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
>=20
> 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.


>=20
> > 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 switch=
ed
> > 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.
> >=20
> > 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.
>=20
> Why do you think that the compiler-warning approach does not work?=20

See all apps compile log for example and you will see a lot of compile=20
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=20
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 figh=
t=20
against it, it's just too bad that we don't use your=20
KF_DISABLE_DEPRECATED_BEFORE_AND_AT for increase porting quality (I explain=
:=20
porting until kf6 and not just porting when we will switch to kf6).

(After that I will continue to use=20
KF_DISABLE_DEPRECATED_BEFORE_AND_AT=3D0x060000 on pim* so I will not wait l=
ast=20
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.=20

> People by the time went and
> adapted the code, thanks to the warnings.
>=20
> 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 :)
>=20
> And with this notice done, I also have a place to point to for everyone w=
ho
> might come after me and the introduction of ECMGenerateExportHeader and a=
ny
> potential issues due to the IMHO misuse of
> KF_DISABLE_DEPRECATED_BEFORE_AND_AT
> :)
>=20
> 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=3D0x05c000
>     -DKF_DEPRECATED_WARNINGS_SINCE=3D0x060000 # default would be: ^
>     -DQT_DISABLE_DEPRECATED_BEFORE=3D0x050900
>     -DQT_DEPRECATED_WARNINGS_SINCE=3D0x060000 # default would be: ^
> )
> --- 8< ---
>=20
> Cheers
> Friedrich


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