Fwd: KDE CI: Administration » Dependency Build Applications kf5-qt5 FreeBSDQt5.15 - Build # 127 - Still Failing!

[Volker Krause]

On Donnerstag, 18. November 2021 19:39:09 CET Friedrich W. H. Kossebau wrote:
> 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 :) )

The end result remains the same though, I have no way of doing such changes in 
KF without risking breakage. It doesn't help the CI that I can argue the way 
the change was done is technically correct.

> 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

Very much appreciated! I hope this will finally allow us to move past this 
issue :)

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20211118/926bb36e/attachment.sig>