-
Notifications
You must be signed in to change notification settings - Fork 17
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
Explicit versionsing of lix-music archive #457
Comments
Hi! I'd prefer an extra git repository over having to keep multiple versions of the music zip file on my webspace. I can then tag the music repo, and github will create versioned zip files from the tags. I can perfectly live with a link (that always provides the newest version) that merely points to a download page (e.g., the github tag page) and have that page automatically offer the newest versioned zip archive. That would be sufficient for Lix's main menu; it tells the player where to download the music. Or do you see another need for a symlink on the webserver? I'll sleep over whether I'd like add such a new music repo as a subrepository of the main Lix repo. It's also possible to put the music files directly into the main Lix repo, but I'm wary of growing the Lix repo too fat over time. There is already a difference between the tracks in lix-music.zip and the tracks in my own Lix binary releases: For Lix 0.10.6 from 2023-02-04, the binary releases changed |
Probably keeping the music files outside the main repo is a good idea. Having a separate one for music sounds good to me - as you noted, it makes it easier to manage changes and do the "releases". Having it (additionally) "mounted" as a submodule in the main one also looks ok - people might skip it if needed, the binary releases also can be done independently. Update. I originally proposed a symlink as the (probably) least intrusive to the current distribution model. The Git approach is a way better for the aforementioned reasons (of course, you still can link in your game domain "to keep the old link(s) correct"). |
I've reuploaded the music archive, fixing the beginning of If new music ever comes around or if there are bigger changes, I'll prioritize this issue (explicit versioning of the music). |
Undo that and create a version 1.1.zip for that. |
^ Lucki attached the 1.0 archive. This is the exact file that @Mailaender had previously pinned in Flatpak. It has a sha256 of If it's such a vital file, I'd prefer not to host it on I'll figure something out for immutable hosting of the music. Most likely, I'll make a github repo (or Codeberg or Sourcehut, as appropriate for FOSS?) and add the 1.0 and 1.1 archives as binary releases. |
Making a Lix package for Fedora, I've encounter one issues.
The music archive for Lix could be versioned. I realize that you might not plan to add extra file to it, but from the packager point of you an used file should be upstream immutable. On the other hand, I realize, that it is handy to have just one link to the latest version. Therefore, I propose to just add the extra link to lix-music-XX.zip (mentioned somewhere in the documentation for packagers) which will always point to the same version (the one valid as for 20230402) and lix-music.zip would internally just symlink to that file.
Once you modify something, then lix-music-YY.zip will be uploaded to the server, with a symlink lix-music.zip switched to the new file (the old one lix-music-XX.zip would stay as it untouched). WDYT?
The text was updated successfully, but these errors were encountered: