On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau <kossebau@kde.org> wrote:
Hi,

((cc:kde-frameworks-devel for heads-up, replies please only to kde-core-deve))

I hit the problem that when working on a repo which would like to use latest
KF development state to integrate some new KF API just added in cooperation
with that very repo wanting to use it, I cannot do so when someone had added a
flatpak job on CI to that repo.

Because with such flatpak jobs it seems they are limiting the available KF
version not to the current latest one, as expected for continuous integration,
but some older (anywhere documented?) snapshot:

    "runtime-version": "6.6-kf6preview",

What can be done here to reestablish the old immediate continuous integration
workflow? Where new APIs (also from KF) are instantly available?

Right now this is a new extra burden which makes working on new features with
KF and apps more complicated. Thus less interesting, and one/I would rather
duplicate code in apps to get things done.

Blocking latest KF API from usage also means less testing of that before the
initial release.

Besides all the resource costs to create flatpaks on master builds by default
every time, when those are usually not used by anyone anyway.

So, how to solve those problems? Did I miss something?
Could flatpak builds on master branches be made on-demand rather?

For the record, my rebuild of the 6.6-kf6preview Flatpak Runtime/SDK was successful, and the failure that kicked this off in KUserFeedback has now been fixed.
https://invent.kde.org/frameworks/kuserfeedback/-/jobs/1561435


Cheers
Friedrich



Cheers,
Ben