Fix compilation after KContacts::Addressee::insertEmail was deprecated
KF 5.88 hasn't been released yet, please don't set KF_DISABLE_DEPRECATED_BEFORE_AND_AT to 5.88 before it's known what exactly will be deprecated in that version. CCMAIL: montel@kde.org
-
Developer
hi, Not I am not agree with it. If it doesn't compile it because we need to adapt code. So you can create a patch as you can use addEmail directly with a check version. Or you wait that someone creates it. (there is some MR for it at the moment) (And I didn't think that you used master as branch for kde).
(adding 0x055800 allows to see when we use new deprecated method in new framework.)
Regards.
-
Author Developer
I just wanted to build
kdepim-runtime
to work on something there (merging the pop3 slave into the pop3 resource, which is something for master, not stable), and I ended up having to dig into a build error inlibkgapi
(before hitting the same issue inkdepim-runtime
). I was surprised that things didn't build and suspected my setup (wrong version of some library) for quite some time -- because the error message didn't even sayAddresse
but some subclass that lives in kdepim, so it really wasn't obvious that the problem came from KF5. And then I wasn't sure that porting toaddEmail
right away, before it's released, would be a good idea (this would then break compilation for kdepim contributors not fully up-to-date with KF5 master). It makes more sense to me to wait a little bit before using new KF API...On the other hand, if you set this var to
0x055800
after 5.88 is released, then you still achieve the same purpose (porting away from deprecated methods) but without creating surprising build breakages for other people. (And it's a lot easier to find out that the breakage is related to KF5 deprecations when it happens as a result of bumping the version number.) -
Developer
"On the other hand, if you set this var to
0x055800
after 5.88 is released, then you still achieve the same purpose (porting away from deprecated methods) but without creating surprising build breakages for other people. (And it's a lot easier to find out that the breakage is related to KF5 deprecations when it happens as a result of bumping the version number.)" I will not the same result as I will necessary to fix X deprecation in same time and not fixing deprecation when it adds in framework repro. it's more easy to fix 1 deprecation by week as 4 deprecations when we release framework. -
Author Developer
Then set
0x555800
locally, without committing it yet, until 5.88 is released.Breaking compilation is never a good way to work as a group and allow external contributions.