Open CliftonH opened 2 years ago
I believe you are correct, but also I want to point out that your versioning scheme is flawed - you cannot use beta1
, beta2
etc, the number at the end is not parsed, it's sorted in simple alphabetical order, so e.g. beta2
> beta10
, which is probably not what you want
Thanks, Ani, you're totally right. We're in the middle of a large refactor of our versioning/updating pipeline to address this and other issues while following a proper semantic versioning scheme, however this bug will still be an issue for us.
@anaisbetts will fix the problem? support semver version spec
@CliftonH how do you resolve the problem?
We have an electron app which follows a semantic versioning scheme with a prerelease suffix to indicate release channel. Our normal release process might include publishing more than one alpha or beta before being published to GA and might look something like this: alpha1 → beta1 → beta2 → GA
specifically:
4.1.0-alpha1
→4.1.0-beta1
→4.1.0-beta2
→4.1.0
We noticed some strange behavior where under certain conditions the updater would indicate that an update is available and would download the update, but would not restart the application running the updated version. I've tracked it down to this line as the root cause. Essentially, when comparing a version number which has a prerelease suffix with one which does not, the version with the suffix is always considered higher. For example,
4.1.0
will always evaluate as lower than4.1.0-beta2
.I assumed the logic here to follow the semantic versioning spec but it does not.