On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau <kosse...@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
