BWS is not fetching the latest Sandrah version if there is an older version already in the BWS downloads folder, because the GitHub master-branch package name doesn't change and the server is not returning a size.
Roxanne, any chance you could start creating GitHub releases so GitHub will generate packages with unique names (commit ID)?
Really? I have not used BWS with EET yet, back when I used it in BGT it was always downloading the newest version...this seems to have changed. I was not aware of it.
So what does your proposal mean? I have no idea how to handle GitHub releases, honestly. Will there be a release for any typo I detect and correct? And does that mean that somebody who once downloaded the mod always will use the old version on any new install unless it is manually deleted in the download folder?
The master branch link is always-latest, but BWS doesn't actually attempt to re-download unless it sees either a file name or size change, and the method used to check the size isn't always successful. When it fails, it falls back to a local copy if the name is as expected... but that isn't the right answer for master archives.
I've now implemented a change in how BWS handles master branch archives, so if it doesn't get a valid size from the server it will assume the local copy is outdated and download again. No action required on your part.
For your reference, creating a GitHub release involves going to the website and using their "draft a release" process. e.g.: https://github.com/R...rahEET/releases
When you create a release, it implicitly creates a Git tag at the then-latest commit of whatever branch you select, and then creates a "release" (which is effectively a bundle of meta-data) that encapsulates that tag. Example: https://github.com/B...rouble/releases
Releases have two types - red (pre-release) and green (regular). You can check a "this is a pre-release" box during the release process. BWS can be configured to download only master branch, only pre-releases, only non-pre-releases, or latest of either release type. Depending on how you prefer to manage your updates, you can use these classifications to "work ahead" of what BWS users will get automatically. For example, if we change BWS to only get non-pre-releases, you can then make changes on the master branch and create pre-releases and none of those changes will be picked up by BWS until you create a new regular release (or edit the latest pre-release and turn it into a regular release).