Am Donnerstag, 18. November 2021, 18:37:37 CET schrieb Volker Krause:
> I looked into this and it seems the problem had already been addressed prior
> to your email, so all I ended up doing is pressing the rebuild button.
>
>
> The change starting this was https://invent.kde.org/frameworks/ki18n/-/
> merge_requests/21, by me. What actually caused the breakage however was the
> way deprecation versions are managed. Not the first time, and not entirely
> surprising, the MR comments even mention that risk.
>
> There's two approaches on how to handle such changes without breaking the
> build:
>
> (1) Change KF, port apps after the next KF release, deprecate old KF API in
> a subsequent release once porting has been completed.
> (2) Change KF and deprecate old API immediately, port apps after the next KF
> release and then bump the deprecation version once that has been completed.
>
> Both have been rejected previously and I have yet to see an alternative
> workflow that allows KF changes/deprecation while avoiding breakage like we
> have seen here. I very much share your frustration in that regard.
The problem is rather the (on purpose) too aggressive setting of the
visibility levels in PIM projects. See also the thread recently here:
https://mail.kde.org/pipermail/kde-pim/2021-August/047845.html
(So as Albert said while I was typing :) )
It is part of the workflow of one big contributor, but sadly has those
negative side-effects for everyone else. In the absence of someone else having
found a solution meanwhile, I will see to finally complete this WE my
technical proposal to this conflict, as sketched at the end of
https://mail.kde.org/pipermail/kde-pim/2021-August/047914.html
Cheers
Friedrich
