Open TiZ-HugLife opened 2 years ago
Hmm, not sure if @Kekun is still active.
Upstream does link to the old versions, looking at their official website, I can see a hidden-ish "Older versions..." which lists v21.09.12.0 and v21.05.08.0 for Linux, furthermore @Eukaryot does seem to tag them in their server, older downloads are available under /sonic3air_game_vXXXXX.tar.gz, where XXXX is the version number without dots.
About using the .php URL directly, it seems to break the build process (I tried it locally), but pointing straight into the download link's proper URL (under the official site) does the trick. I do worry about doing this, since it might burn Eukaryot's bandwidth if we keep doing rebuilds, but otherwise it should be fine since as soon as it is built, it would be getting it from F lathub's infrastructure. At worst, we indeed should mirror it here or alongside the launcher as it is being done.
At least, for getting the game up-to-date and updating GNOME runtime to 42, it is pretty much a matter of changing the runtime and the game's URL link and hash. If nobody picks that up, I'm willing to do a PR and/or maintain this in case of lack of maintainers. Issue #3 was open almost a year ago but it didn't see any activity whatsoever.
Upstream does link to the old versions, looking at their official website, I can see a hidden-ish "Older versions..." which lists v21.09.12.0 and v21.05.08.0 for Linux, furthermore @Eukaryot does seem to tag them in their server, older downloads are available under /sonic3air_game_vXXXXX.tar.gz, where XXXX is the version number without dots.
That's awesome. Then there's not really a whole lot of reason to be using the launcher's repo to host S3AIR's files.
I am willing to pick maintainership on this up as well, since I already did a bunch of work for updating it in #4. I used that opportunity to try to address #3. However, #4 was a very controversial and heated issue. If I were to pick this up, I would not be willing to keep this attached to the GNOME runtime. As Eukaryot said in #4, S3AIR is for all Linux desktops, and it is currently the only game of its sort--one that handles its own rendering and generally runs fullscreen or in a bare window--that targets the GNOME runtime. It's not really appropriate for it to be using the GNOME runtime; it is only used because the included launcher is Adwaita. I addressed that in #4 as well, but I did a bad job of separating my concerns, and ended up holding the S3AIR update hostage pending acceptance of my overhaul, which wasn't really the right thing to do. Granted, S3AIR's data and its appdata.xml are currently beholden to the Adwaita launcher, and that's why I opened #5 and #6.
If you want to keep S3AIR beholden to GNOME's runtime, I imagine you'd have a better chance of taking over maintainership than me, because if Kekun really is inactive and we needed to appeal to have a new maintainer, my plans would be more radical. I would cut out the Adwaita launcher and replace it either with my GTK3 fork, or a Zenity-based alternative, and have S3AIR target the FD.O runtime. I probably wouldn't start with merging #4, but if writing a Zenity-based replacement to the launcher proves to be a pain, I'd probably pull in my fork of the launcher in the interim.
However, if you're content to move S3AIR off of the GNOME runtime onto FD.O, and Kekun really is inactive, we could probably go in on this together. :)
My first concern is getting the game up-to-date with the latest runtime, and from there we can work on moving it off to Freedesktop. That's why I went with a quick-and-dirty "let's update those and see if it builds" after all.
I'm actually pretty neutral to libadwaita issue, personally I like it, but I can see your concerns about using the full GNOME runtime just for a launcher that you will see once at best. Overall I do think going back to GTK3 isn't worth it, simply because it would be run on borrowed time, support for GTK4 on other environments seems to be improving, and as Kekun explained, the dependency tree wouldn't change significantly. In summary, I would be willing to give Zenity a go to slim down the runtime requirements but I am not a fan of the idea of rolling back to GTK3 right now, even if that might be just me looking at all that shiny GTK4 development and going "Oh, cool" lol.
So you want to go to GNOME 42 just to get it up to date immediately, and from there go to FD.O 21.08? I'm cool with that.
So what's the next step, then? Where do we go to request dual maintainership? Matrix? An issue in the main flathub repo?
That's the gist of it.
And apparently, for requesting maintainership, all it takes is an issue on flathub/flathub titled something along the lines of "Request for maintainership of 'xxx.foobar.package'" and its body explaining why. There are about 3 issues with that have this template so it should be a safe bet.
Sounds good. You want to take lead on that, or should I?
I'm writing the request right now, so no worries.
Feel free to replace anything I did regarding this data, I admit I don't remember why I did that exactly at the time but there was a good reason for that (I didn't do that just for fun :upside_down_face:).
Regarding the launcher, IMO what you want is Eukariot to develop something similar directly in the game's engine, it only was a workaround to S3AIR being proprietary.
This is one of those discussion issues I said I would open in closing my pull request.
Right now, S3AIR's data is kept in @Kekun's launcher repo. I'm going to guess that the reasoning for this is so that previous versions can always stay available in case of regressions, because the official upstream source only links to the latest stable and the latest pre-release versions. I think that's probably something worth pursuing, but I also imagine that we could ask @Eukaryot to provide us a way to access all the versions. Right now, the mirror download link is a .php file, which for all we know, could be abstracting away version archives that already exist.
We don't seem to have S3AIR's data as extra-data, which means that as far as I can tell, we bundle it into the Flatpak itself. That means that we pull the data once to build it, and then after that point, Flathub serves that data instead of Eukaryot's server. So could we have access to the version history on the official server?
If not, would it really be such a bad thing to just pull the latest .tar.gz directly from the website? That does mean that if a version is released with a severe enough regression to justify a rollback, we wouldn't be able to do it ourselves, but at the same time, that may also justify a rollback on Eukaryot's end as well. Or does the fact that the download link is a .php file that serves it cause complications for doing that?
I also think that we should move the appdata into this repo instead of the launcher repo, to enforce separation of concerns.