Looks like you've changed the name of the *.desktop file:

/app/share/applications/org.kde.kexi-3.3.desktop

The fix in this case is probably a quick update to the Flatpak ruleset - https://cgit.kde.org/flatpak-kde-applications.git/tree/org.kde.kexi.json

Thanks for the hint.

https://phabricator.kde.org/D18426

Similar question: does the infra allow us to define flatpacks for stable branch? This is badly needed by the users...

From my understanding our repository is only meant to contain nightlies.
Aleix will be able to provide more details regarding this.

@apol Hi Aleix, is there any support for stable builds?

Reassigning this to the Flatpak project, as there is nothing for Sysadmin to do here.

I'm not planning to offer stable releases of KDE software at the moment. I'd like our software maintainers to take responsibility for the binaries we produce. Flathub seems to be reasonably good infrastructure for that so I suggest using it as users already have the remote installed in their systems.

I'm happy to discuss alternatives though.

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?
Bottom line is that for Windows there is no such split and stable software "by KDE" has chance to be shipped.

From the number of flatpacks available I see that majority of the maintainers do not take this extra responsibility. My technical experience also lead me to separating release managers from project managers and technical leaders position...

I would not request to add you more tasks as you're doing awesome job already but I envision possibilities of scaling the projects, especially that KDE and Calligra/KEXI have received funds to expand their availability.

In T10377#174613, @staniek wrote:

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?

I'd say it's not very practical. But we could do it if necessary.

Bottom line is that for Windows there is no such split and stable software "by KDE" has chance to be shipped.

I'd say going all the way on Windows stable releases would mean to get the application on the Windows Store. It should be the maintainer who does that.

From the number of flatpacks available I see that majority of the maintainers do not take this extra responsibility. My technical experience also lead me to separating release managers from project managers and technical leaders position...
I would not request to add you more tasks as you're doing awesome job already but I envision possibilities of scaling the projects, especially that KDE and Calligra/KEXI have received funds to expand their availability.

I don't mind if kexi has 2 leads or one, I just can't be responsible for Kexi QA.
In terms of infrastructure, flathub can already serve to do what you want to do, it's a matter of having somebody care for it and update it on every release. I can help you set it up if you like but I'd like you to take it from there.

With regards to Windows, we do have both unstable nightly builds (which the Binary Factory produces for many projects) along with stable builds (which the Binary Factory also produces).

In terms of the Windows Store, we have an official presence there although uploads of releases are manual (for obvious reasons, in part because they require Microsoft approval and in part because they're destined for consumption by end users).
Please discuss with us regarding this prior to doing anything in respect of the Windows Store or Windows installers in general.

In T10377#174777, @apol wrote:

In T10377#174613, @staniek wrote:

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?

I'd say it's not very practical. But we could do it if necessary.

Bottom line is that for Windows there is no such split and stable software "by KDE" has chance to be shipped.

I'd say going all the way on Windows stable releases would mean to get the application on the Windows Store. It should be the maintainer who does that.

I said - and Ben just repeated Windows has stable and unstable builds working just fine: https://community.kde.org/Kexi/Snapshots#Windows

Windows Store sounds like a principle on which we both agree as long as we stay with theory. But reality is, in case of KEXI, the project is a 0.2 part-time job for one developers.
Background: I think it's not uncommon within KDE application projects. Let's mention entire Calligra. Any delegation of admin/infra task to a developer changes the programming resource to less than 0.2 part time like it or not. And yet it's mixed with inability to raising per-project funds (unless separate own is started like Krita did).

From the number of flatpacks available I see that majority of the maintainers do not take this extra responsibility. My technical experience also lead me to separating release managers from project managers and technical leaders position...
I would not request to add you more tasks as you're doing awesome job already but I envision possibilities of scaling the projects, especially that KDE and Calligra/KEXI have received funds to expand their availability.

I don't mind if kexi has 2 leads or one, I just can't be responsible for Kexi QA.

I would not like to discuss this obligation (QA) with you at all. Windows has stable and unstable builds working just fine https://community.kde.org/Kexi/Snapshots#Windows - and that's _all_ I requested based on common sense and it was delivered in like 2 days. These Windows binaries currently build but do not run. Is it a problem for Hannah von Reth or Ben? Not at all because other folks can fix it, including me - in free time. Great benefit of this is that I do not have give up with programming in favor of maintaining build infra (e.g. for Windows - reinstalling Craft and testing it) - all I do is to fix the issue at source level and wait for next nightly build. Not even a single email has been sent to Hannah or Ben :)

In terms of infrastructure, flathub can already serve to do what you want to do, it's a matter of having somebody care for it and update it on every release. I can help you set it up if you like but I'd like you to take it from there.

I would be grateful for help if Linux can't be supported with stable packages within KDE as Windows is. But if possible I'd prefer to benefit from stable builds within KDE. One approach for all supported systems, one infra and one interface. So either flathub for stable and unstable or KDE for stable and unstable. This increases chance that there's continuous outcome from my 0.2 part time regarding binaries. And chance for more contributors as soon as the projects offer stable binaries.

With regards to the Windows Store - the work by myself and Hannah only extends to publishing on the Binary Factory. Validation of a working application, and then publishing as part of a release (on download.kde.org and the Windows Store) would still be up to a maintainer as part of their release work.

In terms of what's being discussed here I think we're getting things mixed up though.

The Windows Store and Flathub are places users go for final released products which are ready to use. The Binary Factory produces nightlies, which in the case of Windows & Mac, cover two sets of branches: master and stable. For Flatpak we currently only provide the master branch.

What I believe @staniek is after is a nightly build of the stable branch, which is something from my understanding that Flathub is most certainly not intended to provide. I'm not sure how valuable it would be for Binary Factory to offer it either though, given that Flatpak support may need adaptions for things like portals, etc which might be quite invasive (and should thus go to master anyway)

Yes, Ben summarized what I meant. Thanks. We're not yet there (that is, production-ready flatpack or app store of any kind, with QA and regular contributors). We can't have all of this the day one, we need nighties so would-be contributors who are not developers have the chances to test current software (stable/unstable). Current state is that many contributors (power users) run 1 or 2 years old software so even initial conversation within bugs.kde.org is problematic.

And doesn't the nightlies we have now already tackle this?
https://phabricator.kde.org/source/flatpak-kde-applications/browse/master/org.kde.kexi.json

You can pass the branch you want to build with the branch as such (xxxx being the branch name you want):

{
  "name": "kexi",
  "buildsystem": "cmake-ninja",
  "sources": [
    {
      "type": "git",
      "url": "git://anongit.kde.org/kexi.git",
      "branch" : "xxxxx"
    }
  ]
}

@apol Thanks, adding another nightly for other branch was my initial though. Can we add this? We would be done then.

Just to be sure, you want to have it built both for master and specific branches?

Right, for master and stable (currently "3.2").