Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add validation to reject package versions with leading zeros in numeric identifiers (semver v2.0.0) #3648

Closed
xavierdecoster opened this issue Mar 14, 2017 · 6 comments

Comments

@xavierdecoster
Copy link
Member

xavierdecoster commented Mar 14, 2017

Currently, no . characters are allowed in (pre)release labels in the version string, so this is a non-issue currently. However, when introducing semver v2.0.0 support, we should reject packages that use leading zeros in numeric identifiers of release labels.

Example of invalid semver2 version string: 1.0.0-alpha.001
Example of valid semver2 version string (possible today, no numeric identifier parts in release label): 1.0.0-alpha-001

@joelverhagen
Copy link
Member

joelverhagen commented Mar 14, 2017

How is this different than #3482?
edit: fixed link

The mentioned version is already not parsable as a version range:
http://nugettoolsdev.azurewebsites.net/4.0.0-rtm-2265/parse-version-range?versionRange=%5B1.0.0-alpha.001%2C+%29

@xavierdecoster
Copy link
Member Author

You refer to this very same issue?

It may very well be that it is not parsable, but this issue tracks the very fact that gallery doesn't even try to parse/validate it.

@joelverhagen
Copy link
Member

You refer to this very same issue?

😆 oops! Very confusing. Sorry.

I meant #3482.

It may very well be that it is not parsable, but this issue tracks the very fact that gallery doesn't even try to parse/validate it.

Okay, perhaps we're saying the same thing. I don't understand what work there would be to complete this issue on top of the work required to complete #3482.

@xavierdecoster
Copy link
Member Author

One is for dependency version ranges (#3482), the other (#3648) is for the actual package versions :)

@joelverhagen
Copy link
Member

Clear. Thanks!

@xavierdecoster
Copy link
Member Author

This is implicitly fixed by the upgrade to latests NuGet.Versioning and the validation fix #3645. No additional work needed, besides testing, which is tracked by functional test issue #3731.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants