Please reconsider planned build breakage on new KF deprecations

[Sandro Knauß]

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)

I see the problem, that we somehow need a good balance how to treat people to 
fix deprecated stuff and not hit people into there face.

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

Yes but if people develop features, that will be part of master, than it is 
very annoying, that you can not use master, as master is not buildable. And I 
think this is point here. If you just commit the updated 
KF_DISABLE_DEPRECATED_BEFORE_AND_AT master is not buildable. And I think it is 
a common understanding, that the master branch should be buildable all the 
time. Why not develop the cleanup within a branch an merge, if it is clean?

> > 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).

It is not anything aginst your all your work you do for pim. But please see 
also the other side, that people have different workflows and other time 
constrains, to do their stuff.  And also have an open ear for new comers that 
speak out issues, that makes their lifer harder to be work inside our 
community. So at least have a discussion, if we can find a solution here.
 
hefee