Hi, I'm one of the maintainers for Geany's Flathub package. Flathub generally really dislikes shipping regular git builds that aren't releases, mainly because at that point, everything becomes very arbitrary and difficult for maintainers. How do we determine which commit to build from? How often are we expected to pick a "canonical" git commit for the Flathub package? Weekly? Bi-weekly? Monthly? Bi-monthly? Are we expected to support users who pick their own arbitrary commits to build from?

Exceptions can be made, but it's much easier if there is some sort of anchor or waypoint. For example, the Dolphin emulator also has not made a release in over six years, coming up soon on seven. It's safe to assume they will likely just never make a release ever again. But they do monthly progress reports; that is the waypoint around which builds from git are done. The latest commit at the time of publishing a progress report is used to ship git builds of Dolphin. This sounds risky--how can you be sure that the software is in a working state during that commit?--but I believe that Dolphin's developers have a policy of making sure that git master is always usable, doing their heavy lifting, disruptive work in PRs. I don't know if you guys do that too. It's honestly not really my job to know.

So if there's anything you all can do to make choosing git commits more tenable for package maintainers, that will make it feasible for us to ship it in Flathub. I understand that you all probably don't want to be doing progress report blog posts, but if you could make some periodic tags for known good commits, that would probably be good enough for us to start shipping git without having to hold any conversations about it.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.