Keep updated with upstream releases

[jntesteves]

It has been brought up on Reddit that this build has fallen behind upstream by a couple of releases (1.9.5 - 1.9.7). This issue is not so much about updating to that specific version, but to assess the release situation and if there is a chance for improving it.

Is this package maintained by upstream? Can this be made part of upstream's release automation?

[RobLoach]

Would love to see more help maintaining it. Thanks for posting an issue to discuss.

Is this package maintained by upstream?

What do you mean by upstream? I am part of the libretro team, yes. It's not kept as part of the regular release cycle, as there's enough to do as part of that already. I've been out this past week, so haven't had the chance to update it. Would love for others to get involved though, so if you're willing to help out, that would be incredible.

Can this be made part of upstream's release automation?

Would like to automate it in some way. If we get a script in place, it's likely something gitlab ci could handle. What is involved is...

1. Update all commit hashes in org.libretro.retroarch.json
2. Add the release tag in org.libretro.RetroArch.adddata.xml with just changelog notes that affect the Linux build.
3. Make a Pull Request, make sure the tests pass, merge to master

[jntesteves]

I just noticed that the package actually was already on version 1.9.6, not 1.9.5. That's the version I have installed, but Flathub and Gnome Software where wrongly displaying version 1.9.5 as latest version due to a wrong date in org.libretro.RetroArch.appdata.xml. Manually updating 8 commit hashes, a version number and a release date is error prone.

[RobLoach]

Manually updating 8 commit hashes, a version number and a release date is error prone.

Very much so! Would love to clean up the process and leverage as much automation here as possible. Just pushed up 1.9.7, and fixed the appdata.

[jntesteves]

So, it took me a while, I've cloned all repos, skimmed over them a few times over the last week, slept on it. RA is a bit overwhelming for newcomers.

I created #192 as a start. But it is different from your list of tasks.

I understand the problem differently, I think there's little to do in this repo, and the release needs better automation on CI. I noticed that you've added the v1.9.7 tag to several RA repos after the fact (notably, you forgot this very repo). That I consider part of the problem, manually adding tags is error-prone and prone to forgetting. Adding them after the fact, the tags don't mean that the commit they refer to is necessarily the commit that went into that version. There's currently little traceability of what made it into a released build, and reproducibility is unsure. If CI could create the version tags on all repos prior to building, reproducibility would be certain, and then it's easy to just use the tags for refs, no commit hashes necessary.

All RA repos seem to be evergreen, the main branch is always stable and is the branch that goes into a release, so automatically creating tags like this shouldn't be a problem here.

I'm assuming version tags are treated as immutable. That seems to be the case, and it's best practice anyway.

I can't see CI stuff on git.libretro.com, for obvious reasons. I think most work is to be done there. I didn't open an issue for CI yet, though, as I wanted to hear your opinion first, since you understand the release procedures much better than I.

[TiZ-HugLife]

If you make use of flatpak-external-data-checker, then flathubbot will automatically make a pull request whenever a new tag is made for RetroArch. And hence, test builds will also be made for those pull requests. I think relying on FEDC will go a long way toward automating update grind, and doesn't rely on creating any new infrastructure. I'm working on updating RA to the 5.15-21.08 KDE runtime, and will also make a PR for FEDC while I'm at it.

[RobLoach]

@HugLifeTiZ That's awesome! Didn't even know it existed.

[orowith2os]

I can see if I can set up x-checker-data for this Flatpak shortly, remind me whenever if you feel like it and I haven't pushed anything.