Rework update script - #47
Conversation
- return newest linux distros - return oldest win - return oldest macOS (per arch)
| const fallbackDownloadURL = "https://github.com/Cockatrice/Cockatrice/releases/latest"; | ||
|
|
||
| // String ending with separator "-", followed by "OS name", "version digits", "dot", "file extension" | ||
| const windowsRegex = /-(?:Win|Windows)(\d+)\.[^.]+$/i; // e.g. "-Windows10.exe" |
There was a problem hiding this comment.
Would it make more sense to match the file extension exactly in each regex? they are very consistent. In fact, if somehow we ended up with something like "Fedora44.deb", we would not want to match or publish that.
There was a problem hiding this comment.
That is an option for sure, I had that implemented first as well: 6e498f0
I then thought it's too strict and leads to issues if we serve .msi installer for Windows at one point for example.
The case you're describing is an obvious bug or mistake in the main code and core workflow, it should be spotted and fixed there quickly.
Whether the webpage is or is not populating such a download for some hours is not really changing too much.
The webpage code is not well maintained and I see the risk of missed updates here much higher than a misconfiguration going unnoticed for long in the main repo.
But happy to adapt. The matching logic for the in-client updater should probably just stay similar (I just updated that as well with a similar approach).
There was a problem hiding this comment.
I think either way is fine with me, especially if you already considered it.
|
I think changing over to automatic updating is a great idea. One less thing to worry about when releasing a new version. |
|
|
||
| if (versionValue < macOsOldestVersionValue) { | ||
| macOsOldestVersionValue = versionValue; | ||
| macOsTargetVersion = versionValue + "+"; |
There was a problem hiding this comment.
We currently denote this version on the website as "15+ (Apple M)"
There was a problem hiding this comment.
Correct, I dropped that on purpose and simplified to what we use in our file names as well.
macOS is the default and points to Apple Silicon (ARM)
macOS_Intel is a specific version we keep temporarily for legacy Intel support
I might explore universal binaries as well to offer a single download and make it even easier for Mac users.
Not sure how long we actually need to keep the Intel version, Apple dropped support for Intel architecture with macOS 26 already...
There was a problem hiding this comment.
I think being explicit is important here. My experience with mac users has been that they don't know if they have apple silicon or intel or what the difference is. I think if someone sees a button that says Mac 15 and nothing else, they are going to click that and then they may be confused when they can't run the installer because its for the wrong processor. At least if the buttons are labeled "apple silicon" and "intel", a user might be inclined to figure out the difference and which one they need.
As for supporting Intel, Github will support an Intel Mac runner until August 2027 and I think we should support Intel macs as long as we can build for them. macOS 26 supports Intel and will be supported by Apple until 2028 (ish) so I assume some users still need an Intel package. Plus, we generally strive to support any OS that's still in its normal support lifespan.
2 participants
The script for dynamically checking the latest GitHub release and populating download links for our assets was not very flexible and had for example versions hardcoded which required regular manual updates.
Same applied to the naming of the download buttons. They could also mismatch if only the script was updated or a certain asset was no longer available due to a CI issue or version deprecation.
The matching strategy is now smarter, more general and follows the OS-specific compatibility logic.
We find the oldest/newest target version reliably, unrelated of ordering or how the API returns them.
The webpage will always show up to date downloads right after a new release and the script will only require updates for changes in the base asset naming pattern.
Fallbacks are in place:
No version label on each download button and the link points to the latest official GitHub release page for manual inspection in case the script does not find a matching asset (or fails) to update the links.
The indentation change messed the html diff up, sorry.
Pinging @SlightlyCircuitous and @ebbit1q as you worked on the last change on the matching logic and hard coded version numbers/names to get your opinion.