-
-
Notifications
You must be signed in to change notification settings - Fork 792
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add freedesktop compliant appstream & metainfo #11227
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
<url type="vcs-browser">https://github.com/ruffle-rs/ruffle</url> | ||
<url type="contribute">https://github.com/ruffle-rs/ruffle/blob/master/CONTRIBUTING.md</url> | ||
<releases> | ||
<release version="nightly-2023-05-26" date="2022-05-26"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, is this version string supposed to be updated with every nightly release? If so, it may be a good idea to somehow add doing so to CI before this gets merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file should be updated with each release of Ruffle with a basic version and date tags.
But I apologize, I am not familiar with github workflows enough to understand how it can be done.
The basic idea would be to hook onto release-nightly
that commits the repo with the updated metainfo before doing the release process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm somewhat against jamming a commit into master
every single day just for this.
Could this be omitted here?
Perhaps maintained in a separate branch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Standard practice would be updating this file with a changelog. That way users can see in GUI why there is an update and what changes justifying the update. Currently nightlies do not include a changelog, although it would be nice to have one generated so both the metainfo and the github release would have the nightly.
I understand concerns in regards to having this in the main repository. And yes it could be handled in a separate upstream repository, a "ruffle-meta" repository perchance. But then how is versioning handled, syncing the meta repository releases with the main repositories releases?
I also would like to hear feedback from @relrelb who worked on the AUR package who also requires the metainfo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for the changelog, at least GitHub generates one for the nightly releases: https://github.com/ruffle-rs/ruffle/releases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While the expected treatment is to update metainfo with each release. I suppose that is a bit too much for the nightly format.
We can skip over having to update the metainfo until Ruffle stable releases are created.
@relrelb Does that sound good for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another option could be to generate this based on the tag at build time by for example having some easily replaceable pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe every nightly version should be added here, it's not intended for testing or development.
Only stable (a relative term) versions that need to be published should be added.
I wish ruffle-rs had some kind of versions, even if it was alpha for example instead of just nightly builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've long planned to come up with something like that, but there's just no clear point of "when" a release should be cut. Every nightly is basically like the next - with a few exceptions one way or another.
That's why the browser extensions and the Android app are "randomly" published: weekly, or every few days/weeks, basically at random.
The same thing could work here, don't you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think as long as this hardcoded version here is replaced with some sort of @PLACEHOLDER@
, to be substituted just before publishing, this should be fine.
6e2b88d
to
94e0192
Compare
So, do you think the |
94e0192
to
87cc5d4
Compare
Also, by this time, our menu has gained some new items, and the launcher is an "advanced open dialog" now, so could you please update the screenshots? Sorry for dragging this out for so long... |
See for example how the AUR package does it: https://github.com/ruffle-rs/ruffle/blob/master/.github/workflows/release_nightly.yml#L516-L531 I think a similar solution (in the "recipe" to build it) would be fine here as well, as part of: flathub/flathub#4179 |
e9c041c
to
814299e
Compare
Done! |
I saw a Mastodon post about this, does the GitHub actions thing still need help? I would be open to help! |
<control>gamepad</control> | ||
</supports> | ||
<project_license>MIT OR Apache-2.0</project_license> | ||
<developer_name>ruffle-rs</developer_name> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<developer_name>ruffle-rs</developer_name> | |
<developer id="rs.ruffle"> | |
<name translatable="no">ruffle-rs</name> | |
</developer> |
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer_name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The standard says to use a URL, where does it say to use reverse-URL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it was a person for example in github it should be io.github.x
, but if it was the organization shouldn't it be like io.github
?
Any way it Ok to use a normal URL as long as it is always unique. The standard is not specific about this.
Any way the method used should be unified for developers under the ruffle-rs name.
<screenshot type="default"> | ||
<image>https://raw.githubusercontent.com/ruffle-rs/ruffle/master/desktop/packages/linux/launcher.png</image> | ||
</screenshot> | ||
<screenshot> | ||
<image>https://raw.githubusercontent.com/ruffle-rs/ruffle/master/desktop/packages/linux/btd.png</image> | ||
</screenshot> | ||
<screenshot> | ||
<image>https://raw.githubusercontent.com/ruffle-rs/ruffle/master/desktop/packages/linux/ltf.png</image> | ||
</screenshot> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those URLs should point to something more stable like a commit.
Yes! |
Good, I'll look into that when I have time! 🥳 |
b0d754d
to
ed4c84f
Compare
Refreshed this PR a bit, most notable changes:
To do:
|
ed4c84f
to
69462ff
Compare
15660e4
to
792f3d5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see my version-number-related complaints no longer apply (as there aren't any <releases>
), and all my other notes are just nits that can be ignored at will. Thank you to all whomst hath contributed!
79170f6
to
53abefc
Compare
53abefc
to
d60a883
Compare
7801282
to
c00ead0
Compare
c00ead0
to
5e18a00
Compare
Thank you to all the contributors! |
Validated to match requirements set by freedesktop via
desktop-file-check
andflatpak run org.freedesktop.appstream-glib validate rs.ruffle.Ruffle.metainfo.xml
.Related: #9220