Describe the bug
The current format is <version>-<hash>, but the hash might start with a leading 0, which is illegal syntax under SemVer 2.0.0.
For example, if the package is named 1.73.0-0eee625fae7ef2f8964954575ab351ff5916ae83, it would be parsed as Version "1.73.0" and pre-release info "0eee625fae7ef2f8964954575ab351ff5916ae83", but the leading 0 is invalid here since this is not a numeric identifier. See the full spec here.
Environment
- OS: Windows 10
- Compiler: msvc 19.28.29333
To Reproduce
Steps to reproduce the behavior:
- Configure binary caching on Nuget server
- vcpkg install (any package)
- after compilation, package is pushed to Nuget server
- Open up a browser and navigate to your Nuget server's package search page. Look for the package just uploaded.
Notice that the UI (I'm using Baget server) is all weird, because of Node's semver library unable to parse the versions correctly.
Expected behavior
The version of the nuget package should be a valid SemVer string. One way to achieve that would be to simply prepend a non-digit in front of the hash, like "1.73.0-h0eee625fae7ef2f8964954575ab351ff5916ae83"
Failure logs
I had to create a sandboxed Node.js project to verify all this, so I don't have a failure log to provide.
Additional context
Why does vcpkg chose to use "pre-release information" to store the hash? It would be more semantically correct to use "build metadata", since this is exactly what this hash represents: the complete information about the build environment. But one has to consider the implication about version precedence: the pre-release info is part of the precedence, while build metadata is not. However I would argue that since it is a hash, and thus randomly distributed, the ordering is already broken, and it would be better to just remove that hash from the ordering.
Describe the bug
The current format is
<version>-<hash>, but the hash might start with a leading 0, which is illegal syntax under SemVer 2.0.0.For example, if the package is named
1.73.0-0eee625fae7ef2f8964954575ab351ff5916ae83, it would be parsed as Version "1.73.0" and pre-release info "0eee625fae7ef2f8964954575ab351ff5916ae83", but the leading 0 is invalid here since this is not a numeric identifier. See the full spec here.Environment
To Reproduce
Steps to reproduce the behavior:
Notice that the UI (I'm using Baget server) is all weird, because of Node's semver library unable to parse the versions correctly.
Expected behavior
The version of the nuget package should be a valid SemVer string. One way to achieve that would be to simply prepend a non-digit in front of the hash, like "1.73.0-h0eee625fae7ef2f8964954575ab351ff5916ae83"
Failure logs
I had to create a sandboxed Node.js project to verify all this, so I don't have a failure log to provide.
Additional context
Why does vcpkg chose to use "pre-release information" to store the hash? It would be more semantically correct to use "build metadata", since this is exactly what this hash represents: the complete information about the build environment. But one has to consider the implication about version precedence: the pre-release info is part of the precedence, while build metadata is not. However I would argue that since it is a hash, and thus randomly distributed, the ordering is already broken, and it would be better to just remove that hash from the ordering.