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?