Closed Athanasius closed 4 years ago
My workaround for now (this is in Python):
appversion_nobuildmetadata = appversion.split(sep='+')[0]
print('Version used for WinSparkle: {}'.format(appversion_nobuildmetadata))
self.updater.win_sparkle_set_app_build_version(appversion_nobuildmetadata)```
So, any plans for an option to have version checking follow Semantic Version rules ?
Well, you're the one who cares about this, so why not contribute a PR back to the project?
As a rule of thumb, compatibility with Sparkle is an important consideration. A difference in how comparison behaves in WinSparkle, with reproduction test case, is considered a bug in WinSparkle.
Finally, note that sparkle feeds operate with two version numbers, allowing decoupling of version numbers that are user visible and that are used for comparison.
I'm trying to properly use Semantic Versions in a project.
I was happy to see that the current implementation of SplitVersionString (https://github.com/vslavik/winsparkle/blob/master/src/updatechecker.cpp#L75-L77) naturally supports the 'pre-release' segment, just due to how it splits the string.
However, as there's no special handling of SemVer's
+build
it's treated as part of the version for comparison purposes, which is incorrect for Semantic Versions:https://semver.org/#semantic-versioning-specification-semver - Point 10:
i.e. WinSparkle considers 1.2.3-beta1+build6 to be larger than 1.2.3-beta1+build7, which you might naively think is wanted, but what if it's 1.2.3-beta1+f7aa85a versus 1.23-beta1+a89b23 (i.e. git short tag as build metadata) ? They should be considered the same version.
So, any plans for an option to have version checking follow Semantic Version rules ?
In the meantime I'll see if there's a WinSparkle API hook I can use to trim the build metadata off, or if needs be fork and compile my own version with tweaks.