Best practices to distribute flatpak apps in gnome-nightly repository

I wonder if you’ve ever discussed about the need of some best practices to distribute GNOME apps via gnome-nightly.
The Apps/Nightly page in the wiki is addressed to users only.

I think there are at least two topics to be discussed.

1. Name scheme

If you run flatpak remote-ls --app gnome-nightly, you’ll see that different schemes are used for a nightly app:

  • APP.Devel (my favorite)
  • APPDevel (I dislike it)
  • APP, that is the same id of the stable app: I would discourage this in gnome-nightly as it doesn’t allow to run concurrent installations from the shell (only from the terminal by appending the branch name). On the other hand, the same id means same config and data files, which could be good or bad depending on the project.

2. Version scheme

I decided to open this topic after discussing with @mjog about Geary nightly version in Geary issue 1152.

Geary nightly is currently seen by flatpak as 3.38 even though it’s actually 40.alpha. Why? Because in the appdata file the latest release with a date is version 3.38.
Now the problem is that I’d like to see 40.alpha, but 40.alpha has not been released yet. IMO development releases (.alpha, .beta and .rc) should be added to the appdata file with the date their development cycle begins (while stable releases will have a date when their development cycle ends). This seems to be the only way to have a correct version in nightly apps. I see that some apps (Epiphany, Nautilus, Chess, LightsOff and others) are already following this approach use 40.alpha or 40.beta.

Appdata allows to mark a release as development. Here’s an example:

<release version="40.alpha" date="2021-01-18" type="development">

That line should be changed to 40.beta and a new date when beta development begins. Same for 40.rc.

Eventually when 40.0 is released, it will become:

<release version="40.0" date="2021-XX-YY">

What do you think?

1 Like

Looking at Nautilus git history, their appdata file contains a single release. Development releases are treated as regular releases, i.e. 40.alpha is released at the end of its development cycle. I guess it’s something we should stick at. However, every nightly after 40.alpha release and before 40.beta release will appear as 40.alpha even though it’s diverging from it. I guess it’s an acceptable trade off.

Another solution was suggested by Mike in the above Geary issue:

I’d be pretty amenable to making the next future feature release named something like “40.nightly” and have meson update the date attribute for that automatically at configure/build/install time with the date of the build. This would solve the issue at hand in a way that works for both of us.

Feedback is welcome!

Let me suggest one advantage of the AppDevel style (vs the App.Devel style). Flatpak will let you own dbus names “below” your namespace. For example, the App flatpak can claim App.Settings, App.Monitor, App.Devel, etc.

It feels wrong to me that the nightly version of an app would have a namespace inside the namespace of the stable version. It feels more appropriate (to my mind) that they are treated as wholly separate apps by the system, with no bleeding into each other.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.