<div dir="ltr"><div dir="ltr">On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau <<a href="mailto:kossebau@kde.org" target="_blank">kossebau@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
((cc:kde-frameworks-devel for heads-up, replies please only to kde-core-deve))<br>
<br>
I hit the problem that when working on a repo which would like to use latest <br>
KF development state to integrate some new KF API just added in cooperation <br>
with that very repo wanting to use it, I cannot do so when someone had added a <br>
flatpak job on CI to that repo.<br>
<br>
Because with such flatpak jobs it seems they are limiting the available KF <br>
version not to the current latest one, as expected for continuous integration, <br>
but some older (anywhere documented?) snapshot:<br>
<br>
    "runtime-version": "6.6-kf6preview",<br></blockquote><div><br></div><div>Please see <a href="https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6">https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6</a> for what is in the KF6 preview.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What can be done here to reestablish the old immediate continuous integration <br>
workflow? Where new APIs (also from KF) are instantly available?<br></blockquote><div><br></div><div>With Flatpak new APIs were never instantly available - there has always been a delay as the Flatpak Runtime uses the most recent released version of our software.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Right now this is a new extra burden which makes working on new features with <br>
KF and apps more complicated. Thus less interesting, and one/I would rather <br>
duplicate code in apps to get things done.<br>
<br>
Blocking latest KF API from usage also means less testing of that before the <br>
initial release. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Besides all the resource costs to create flatpaks on master builds by default <br>
every time, when those are usually not used by anyone anyway.<br></blockquote><div><br></div><div>Those applications that have a hard dependency on features being added to Frameworks are not good candidates for making use of our Continuous Delivery systems i'm afraid.</div><div>Both Flatpak and Craft based (Linux Appimages, Android APKs, Windows and macOS) CD jobs are best optimised for those applications that rely on the stable Frameworks releases.</div><div><br></div><div>There are ways (in .craft.ini) to make newer Frameworks available, but that requires that the system recompiles that Framework each time you trigger a build and is therefore not recommended.</div><div> </div><div>Allowing those systems to use the "latest" artifacts of Frameworks would be a non-trivial exercise.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So, how to solve those problems? Did I miss something?<br>
Could flatpak builds on master branches be made on-demand rather?</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers<br>
Friedrich<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>