Please reconsider planned build breakage on new KF deprecations

[Laurent Montel]

On mercredi 18 août 2021 16:27:29 CEST Friedrich W. H. Kossebau wrote:
> Hi,
> 
> the recent deprecations in KF master around KPluginLoader broke some PIM
> builds for me, due to KF_DISABLE_DEPRECATED_BEFORE_AND_AT being set to a
> number only matching the upcoming KF versions, thus immediately changing
> things when new deprecations come up.

Hi,
For me the problem is that we mark as deprecated before porting code.
Volker methods was better, porting all code to new code (when it’s possible) 
and after mark them as deprecated.
For the moment we mark method as deprecated and nobody port them.
So using KF_DISABLE_DEPRECATED_BEFORE_AND_AT is good for it to avoiding to 
wait x months before porting them. (as for sure I will need to port it)

If you want to have a stable dep you can use 21.08 branch.

> 
> As someone who also works on KF once in a while (mainly for fixing things
> upstream where needed), thus builds latest KF master every few days, this
> now got heavily in my way and killed some time and energy.
> 
> I urge to reconsider this decision to enforce breakages of PIM master on new
> deprecations in KF master.

> For me, it today wasted time resources and will also waste more, as I
> * had to invest to find if my WIP patches broke things
> * had to invest into work-arounds, which also need future care
> * lost concentration and my mental setup around the current WIP
> * (and had to invest into frustration management)

As you write “for you".

> I totally understand the need to deal with usages of deprecated API in a
> timely manner to prepare for the future (being the who invested into having
> the option with KF libraries for eloborated deprecation markup, compare also
> https://frinring.wordpress.com/2019/09/09/more-control-over-warnings-for-an
> d-visibility-of-deprecated-library-api-via-generated-export-macro-header/).
> 
> But I think that forcing people immediately into working on porting away
> from deprecated API by planned builds breakages is just wrong. Is it more
> urgent than fixing bugs & regressions? I think no.

I think yes. As I prepare future qt6/kf6.
And for sure I fix a lot of regression/bug in pim* from long time.
(You just work on pim* from some weeks, I work from some years and I don’t 
want to wait x months for porting deprecated methods).

> There are so many unit tests broken in PIM, and so far there have been at
> least two more serious regressions uncovered by the recent unit test fixes.
> Then PIM code itself has lots of own deprecations which have not been dealt
> with in many years. This feels out of proportions to me.
> 
> Please reconsider the priorities here and the application of technology.
> For myself, hitting this issue just harmed my motivation to a good degree,
> as I do not like to spend my time on things which have little or no use,
> there are other things in life to have fun with in the same time.

We have different motivation :)

> 
> I wonder: who is in favour of the current approach?

+1 for keeping KF_DISABLE_DEPRECATED_BEFORE_AND_AT

> Who is not in favour?
> Could this be agreed on to be changed?

nope
> 
> Cheers
> Friedrich


-- 
Laurent Montel | laurent.montel at 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, http://www.kdab.fr
KDAB - The Qt, C++ and OpenGL Experts