Skip to content
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

Merged
merged 3 commits into from
Aug 3, 2024

Conversation

Doomsdayrs
Copy link
Contributor

@Doomsdayrs Doomsdayrs commented May 26, 2023

Validated to match requirements set by freedesktop via desktop-file-check and flatpak run org.freedesktop.appstream-glib validate rs.ruffle.Ruffle.metainfo.xml.


Related: #9220

This was referenced May 26, 2023
@Doomsdayrs
Copy link
Contributor Author

Doomsdayrs commented May 30, 2023

Note, If the metainfo file is accepted upstream, it is expected to be automatically updated by upstream as well with each release of Ruffle (or pre-release with the current model).

Copy link
Contributor

@Dinnerbone Dinnerbone left a 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"/>
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link

@zefr0x zefr0x Feb 13, 2024

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.

Copy link
Member

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?

Copy link
Member

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.

@torokati44
Copy link
Member

So, do you think the <release version="nightly-2023-05-26" date="2022-05-26"/> issue could be automated away somehow, so that it's not hardcoded in the repo, and doesn't need to be updated - rather, filled out as part of the flatpak build process?
Perhaps https://github.com/ruffle-rs/ruffle/blob/master/web/packages/core/tools/set_version.js can give some inspiration - it could even be used as is, and then copying the version over from the .json to the .xml somehow?

@torokati44
Copy link
Member

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...

@torokati44
Copy link
Member

filled out as part of the flatpak build process

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

@Lord-McSweeney Lord-McSweeney added desktop waiting-on-author Waiting on the PR author to make the requested changes labels Dec 14, 2023
@Doomsdayrs
Copy link
Contributor Author

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...

Done!

@jh-devv
Copy link

jh-devv commented Feb 23, 2024

I saw a Mastodon post about this, does the GitHub actions thing still need help? I would be open to help!

desktop/packages/linux/rs.ruffle.Ruffle.metainfo.xml Outdated Show resolved Hide resolved
desktop/packages/linux/rs.ruffle.Ruffle.metainfo.xml Outdated Show resolved Hide resolved
<control>gamepad</control>
</supports>
<project_license>MIT OR Apache-2.0</project_license>
<developer_name>ruffle-rs</developer_name>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<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

Copy link
Contributor Author

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?

Copy link

@zefr0x zefr0x Feb 23, 2024

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.

desktop/packages/linux/rs.ruffle.Ruffle.desktop Outdated Show resolved Hide resolved
desktop/packages/linux/rs.ruffle.Ruffle.metainfo.xml Outdated Show resolved Hide resolved
Comment on lines 10 to 18
<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>
Copy link

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.

@Doomsdayrs
Copy link
Contributor Author

I saw a Mastodon post about this, does the GitHub actions thing still need help? I would be open to help!

Yes!

@jh-devv
Copy link

jh-devv commented Feb 26, 2024

I saw a Mastodon post about this, does the GitHub actions thing still need help? I would be open to help!

Yes!

Good, I'll look into that when I have time! 🥳

@kjarosh kjarosh self-assigned this Jul 22, 2024
@kjarosh
Copy link
Member

kjarosh commented Jul 22, 2024

Refreshed this PR a bit, most notable changes:

  • updated screenshots (ensured that window shadow and rounded corners are included as per the guidelines),
  • updated URLs (to conform to appstream spec),
  • updated the update_contact to our official email address and made the developer name more human-friendly,
  • removed list of releases (we will have to figure this out in the future — either update them automatically each stable release or fill them when building the flatpak).

To do:

@kjarosh kjarosh added waiting-on-review Waiting on review from a Ruffle team member and removed waiting-on-author Waiting on the PR author to make the requested changes labels Aug 1, 2024
@kjarosh kjarosh requested a review from torokati44 August 1, 2024 22:17
@kjarosh kjarosh force-pushed the freedesktop-compliance branch 2 times, most recently from 15660e4 to 792f3d5 Compare August 2, 2024 10:31
Copy link
Member

@torokati44 torokati44 left a 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!

@kjarosh kjarosh force-pushed the freedesktop-compliance branch 2 times, most recently from 79170f6 to 53abefc Compare August 2, 2024 16:20
@kjarosh kjarosh force-pushed the freedesktop-compliance branch 3 times, most recently from 7801282 to c00ead0 Compare August 3, 2024 14:22
@kjarosh
Copy link
Member

kjarosh commented Aug 3, 2024

Thank you to all the contributors!

@kjarosh kjarosh merged commit efe754c into ruffle-rs:master Aug 3, 2024
16 of 17 checks passed
@kjarosh kjarosh removed the waiting-on-review Waiting on review from a Ruffle team member label Aug 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet