FR: Version tags

[tim77]

Hello. To help maintainers with update would be nice to start tagging interim versions and sync with RetroArch. Similar to libretro-database, retroarch-joypad-autoconfig, etc.

[baxysquare]

You're right it would be nice. However, this repository is a much slower moving one, compared to the ones you're referring to. Long-term, we plan to completely revamp the repository to support unified themes that will benefit all the different supported UIs. Until that is fully implemented, it probably makes sense for us to leave it as-is.

[RogueScholar]

@baxysquare, would you be amenable to reconsidering that decision? As I see it, @tim77's proposal warrants implementing for some very simple reasons, chief among them:

• It costs almost nothing. It's nothing more than amending the established release process to include the act of creating a tag in the log here concurrent with the one made in the parent repository for each release.
• The benefits are obvious, at least they are to me. Such tags being made here could serve as communications channels, alerting maintainers to the need to update their packages so they remain in sync with RA, or even triggering a CI workflow designed to automate such efforts. They also allow for those packages to be consistent across distribution channels, since everyone could pull the tag matching the parent release rather than each maintainer reviewing the log and using their own judgment to determine the appropriate commit to base their work on.
• He asked nicely. We should always try to accommodate the needs of others when their requests are trivial, especially when they do so considerately.

Tying this repository into the release checklist for the larger project would have no impact on the "speed at which this repository makes changes," or at least it need not. A rubric could be agreed upon which made a clear distinction between design tags (marking substantial changes in the UI elements contained here) and snapshot tags, which would only serve to organize the work happening here at whatever pace it chooses. I don't disagree that this repository would likely benefit from also having the ability to operate its own release cycle based on the design evolutions that take place here, either. Fortunately, they are not mutually exclusive.

Is there an established process by which the release process can be amended? Perhaps a release manager could be pinged to join this conversation and weigh in with their thoughts. I can see a clear benefit from this for my own efforts helping to maintain the Debian Linux packages in the Libretro PPA on Launchpad.

[baxysquare]

@RogueScholar I sincerely apologize if I made it sound like I was opposed to the request from @tim77. Please note that I did not mean to have even a hint of sarcasm when I said "You're right it would be nice." I legitimately feel this is a good idea. This issue is still an open one that deserves to be considered.

Originally, the question really came down to "when" we could or should tag interim versions and sync with RetroArch. At the time, I believed that the best time to implement is when we revamp for unified themes. But it doesn't seem like there's much interest in making that happen over the last four years. The idea lost momentum when @jdgleaver left the scene. I relented about 6 months ago and converted the FlatUX theme which was intended as the first universal theme, for use in the XMB, and it's still waiting to become an active, selectable theme in RetroArch/Lakka.

If someone wants to start tagging interim versions and sync with RetroArch ASAP, it would be a welcome addition. I'd love to have release manager(s) step up and help me out. The repository is in desperate need of assistance and contributions, especially from coders and Github masters. Most contributors in this repository are artists and designers, and the learning curve for Github can be intimidating.

I'd really like to see this repository become a place where designers and coders can come together to improve the RetroArch user experience. In order to get there, I could really, really use some help.

[RobLoach]

If someone wants to start tagging interim versions

I'm happy to help out with tagging the releases. Been handling it for the other repositories listed above to tag the Flatpak release. What I would need though is commit/maintainer access on the repository. Are you able to add me?

[baxysquare]

@RobLoach Thanks for volunteering to help. You should now have the access you need.

[RobLoach]

Tagged v1.15.0+... Thanks, all! Happy to keep these going.

[RogueScholar]

I hate to add anything more to your plate, @RobLoach, but if you were able to tag a commit to align with the v1.20.0 release sometime when you're not stretched too thin, that would be marvelous. 🥰

---

A brief bit of bellyaching…

I'm reticent to be a squeaky wheel here, but having just reworked the packaging files for the the Launchpad PPA's retroarch-assets, I doubt I'll ever have a better handle on the state of the repo than at present. The issue I'm less-than-thrilled about is the somewhat disheveled organizational state here, or more specifically, the massive number of binary objects that have been checked in over the years. When working with this repo manually from the CLI, of course I'm able to filter my clones and apply depth restrictions, but environments like the Launchpad buildd lack any of those knobs to twist. It pulls a complete copy of the entire history for every package build, resulting in every single source package archive being 435MiB, which comically dwarfs the corresponding binary packages which are only 153.5MiB each. Not only does that make the build process slow as molasses, it's also the odds-on favorite to be the culprit anytime the PPAs get frozen for exceeding the storage budget.

I'm aware that there's a broader philosophical restructuring that's been percolating here and any procedural remedies for this issue ought to occur as a facet of that, so this is basically just me whinging as opposed to advocating for a particular solution at the moment. If it were feasible in the near-term to carve off a branch that was strictly confined to just the source files but no binary artifacts, I'd (selfishly) be thrilled, though I suspect the only viable long-term solution needs to spring from a vastly modified workflow for this aspect of RA altogether. If there's any sort of tracking document or workboard for the organizing effort, I'd enjoy having a look at it in the hopes of having a more constructive idea of how best to add my shoulder to that grindstone.

Having said all that, I don't want to sign off before also acknowledging the great work going on here to polish and beautify the RetroArch UI. To say that it's barely recognizable as the same app I began using 8+ years ago is putting it mildly. Bravo to you all, truly.

Warmly,
Peter (RogueScholar)

[RobLoach]

https://github.com/libretro/retroarch-assets/releases/tag/v1.20.0

As for the Launchpad sources, thank you! Those are so often our of date, so any attention is fantastic.

Instead of the full source, could we get it to download just the important files? I'll make an issue to follow up.

[baxysquare]

@RogueScholar We appreciate both your praise and your criticism. Reducing the size of the repository has been a goal for as long as I've been contributing. I'll reply over on #485 with some ideas.