Add support for Curse alpha/beta addon releases
Closed this issue · 6 comments
Curse allows authors to upload alpha and beta versions of addons, which are not found by the tool. Any package that lacks a full release version entirely can't be installed with the tool.
The simple solution may just be to fall back to finding beta and then alpha versions if possible. That probably isn't easy, but it's possible.
Hey, I started working on this over in https://github.com/amas0/wow-addon-updater/tree/curse-alpha-beta.
The main changes involve scraping the /files page of a given addon (such as here) instead of the main page. This gives access to all releases including alpha and beta releases, broken down by which version they support. The bulk of this logic is done by defining a Curse.versions() generator that yields objects that have metadata on the specific releases, which can then be used by Curse.get_latest_version() and Curse.find_zip_url().
I wanted to ask your opinion on a point as I continue working this:
How would you like to handle the user specifying they would like to track the alpha or beta release tracks?
I was thinking something like having the addons.txt file look something like this:
https://www.curseforge.com/wow/addons/clique beta
If a user wanted to follow the beta track. This could be parsed by the AddonManager and would pass it along to the Curse handler if necessary. Omitting a release track would just follow full releases as is currently supported.
How would you like to handle the user specifying they would like to track the alpha or beta release tracks?
I think your proposal is great, provided the fallback behavior for existing users is to do-nothing when missing a prerelease identifier.
As the “sub folder” extracting is also a syntax trick, I would just like to bring that to your attention, and make sure that a pattern like
https://www.curseforge.com/wow/addons/clique|subfolder_name beta
remains parseable.
Thank you for the awesome contributions! I hope this tool continues to drive lots of happy addon installations. 😌
I am on holiday now and for a few more days, so I will review your fork once I have access to my machine again. Thanks
Sounds good!
In regards to:
...provided the fallback behavior for existing users is to do-nothing when missing a prerelease identifier
Just to clarify, you just want to make sure there aren't any breaking changes for existing users? My plan is to have the absence of an identifier just fallback on tracking the normal "official release" track, which is the current behavior of the tool.
I'm going to work on putting together a proper pull request with these changes if you don't have any glaring issues with them.
Just to clarify, you just want to make sure there aren't any breaking changes for existing users?
Yes, exactly. Thank you!
Added with #153