KDE Gear projects with failing CI (master) (9 April 2024)

Friedrich W. H. Kossebau kossebau at kde.org
Wed Apr 10 12:33:46 BST 2024

Am Mittwoch, 10. April 2024, 13:04:47 CEST schrieb Ingo Klöcker:
> On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote:
> > On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker <kloecker at kde.org> wrote:
> > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote:
> > > > ktrip - NEW
> > > > 
> > > >  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
> > > >  
> > > >   * craft_android builds fail
> > > 
> > > *sigh* Why does kirigami master depend on the not yet released ECM
> > > 6.1.0?
> > 
> > Likely as Kirigami itself is a Framework - that being said, it seems a bit
> > weird for the version bumps to be pushed to Frameworks before the release
> > has been made public (because Craft cannot use them until they're
> > public...)
> I learned that this is the usual procedure for Frameworks. But it highlights
> why it's a bad idea for applications to depend on the master versions of
> Frameworks.

In (software) development it seems usually fine to have development branches 
of separate components depend on each other's latest state. They call it 
Continuous Integration. One of the purposes is to get early-as-possible 
feedback, not only post-release when certain things can no longer be changed.
In the case of KF libraries that would be e.g. feasibility of new API as well 
as the state of the implementation. Which is usually considered a good idea, 
both for the libraries as well as the applications as the consumers of the 

It is a bad idea only from the POV of Craft users, as the tool seems not yet 
capable to deal with development branches of all dependencies?
E.g. kdesrc-build/kde-build though e.g. are capable, so let's hope some Craft 
developers/users are inspired to have their tool catch up.

Even more when Craft is thought to also support early testing by users of new 
features/implementation (that is why you do packages for app development 
states here, right?), where development branches of the respective libraries 
adding to that also want/need to be covered.


More information about the kde-devel mailing list