--nextPart13493454.uLZWGnKmhe
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
From: Ingo =?ISO-8859-1?Q?Kl=F6cker?= <kloecker@kde.org>
To: kde-devel@kde.org
Subject: Re: KDE Gear projects with failing CI (master) (9 April 2024)
Date: Wed, 10 Apr 2024 14:29:37 +0200
Message-ID: <2183522.irdbgypaU6@daneel>
In-Reply-To: <1866635.LH7GnMWURc@klux>
MIME-Version: 1.0

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=C3=B6cker:
> > On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote:
> > > On Wed, Apr 10, 2024 at 9:51=E2=80=AFAM Ingo Kl=C3=B6cker <kloecker@k=
de.org> wrote:
> > > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote:
> > > > > ktrip - NEW
> > > > >=20
> > > > >  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
> > > > > =20
> > > > >   * craft_android builds fail
> > > >=20
> > > > *sigh* Why does kirigami master depend on the not yet released ECM
> > > > 6.1.0?
> > >=20
> > > 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...)
> >=20
> > 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.
>=20
> In (software) development it seems usually fine to have development branc=
hes
> 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 consider=
ed
> a good idea, both for the libraries as well as the applications as the
> consumers of the libraries.
>=20
> 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 jo=
b=20
builds all Frameworks from scratch. In any case, what you talk about is=20
covered by the CI (Continuous Integration!) jobs.

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

Regards,
Ingo
--nextPart13493454.uLZWGnKmhe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTbjgIOMowwlCBgvyGxb1mVFkdKugUCZhaGMQAKCRCxb1mVFkdK
ukbvAQCKK6dElgr2asolOHz7v6jG7EQDR4SWRCnTnXSOYl63JAEApBk3nyCjvjsT
2sEEZdI37x+EqcfS3ECbsiM+sWpa1w8=
=BsE/
-----END PGP SIGNATURE-----

--nextPart13493454.uLZWGnKmhe--