[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE Gear projects with failing CI (master) (9 April 2024)
From:       Ingo =?ISO-8859-1?Q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2024-04-10 12:29:37
Message-ID: 2183522.irdbgypaU6 () daneel
[Download RAW message or body]


On Mittwoch, 10. April 2024 13:33:46 CEST Friedrich W. H. Kossebau wrote:
> 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@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 libraries.
> 
> 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?

It does support this but it will kill our CI/CD system if every Craft CD job 
builds all Frameworks from scratch. In any case, what you talk about is 
covered by the CI (Continuous Integration!) jobs.

The Craft CD (Continuous Delivery/Deployment) jobs are meant to be used for 
building releases. When we stop doing fixed point releases and start doing 
continuous releases of Frameworks then we can talk about doing CD from master.

Regards,
Ingo
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]