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

Non-SemVer package versions (with 4 parts) #7376

Closed
FlorianHockmann opened this issue Oct 8, 2018 · 3 comments
Closed

Non-SemVer package versions (with 4 parts) #7376

FlorianHockmann opened this issue Oct 8, 2018 · 3 comments
Labels
Area:PackageDefinition Resolution:Question This issues appears to be a question, not a product defect WaitingForCustomer Applied when a NuGet triage person needs more info from the OP

Comments

@FlorianHockmann
Copy link

First of all, I hope this is the right place to ask such a question. If not, please feel free to close this and direct me in the right direction.

Is using a SemVer compatible version number a requirement for NuGet packages? The only documentation I could find on this topic talks about SemVer for package versions but it also briefly mentions the possibility of having four part versions:

A zero in the fourth part of the version number

So, is it possible to use a version number that consists of four parts for a NuGet package? And if it is possible: Does that come with any disadvantages?

The use case is that we are currently working on a database driver and wondered whether we could include the version number of the database in the version of the library to communicate to users which version of the library is compatible with which version of the database. Since the database already has a version number that consists of three parts (like 0.3.0), a fourth part seems to be necessary to differentiate between versions of the library for the same database version (like 0.3.0.1, 0.3.0.2, and so on).

(Some context: The database in question is JanusGraph and we are currently discussing about how to handle versioning for driver libraries.)

@StingyJack
Copy link
Contributor

StingyJack commented Oct 21, 2018

Nuget pack will alter the version number by dropping 0's in the 4th part, forcing semver in these cases but not in others.

It makes package versions go
1.1.1.5
1.1.1.6
1.1.1.7
1.1.2. (instead of 1.1.2.0)
1.1.2.1
Etc...

There is at least one issue here for "unwanted version normalization" regarding this. There are a few others that describe the normalization added in nuget 3.5

@nkolev92
Copy link
Member

Since 3.4+ nuget has been normalizing the 4th part version of packages.

It also considers 1.1.1 and 1.1.1.0 to be equivalent, as the doc you linked indicated.

They are supported, but we'd discourage that.

If you want to add build versions, I'd recommend you use semver2 compatible prerelease versions.

Say have something like, 2.1.0-preview.1.5667

@nkolev92 nkolev92 added Resolution:Question This issues appears to be a question, not a product defect Area:PackageDefinition WaitingForCustomer Applied when a NuGet triage person needs more info from the OP labels Jan 25, 2019
@FlorianHockmann
Copy link
Author

OK, thanks for the clarification, especially for this sentence:

They are supported, but we'd discourage that.

which is also how I interpreted the docs (although I think that it wouldn't hurt to include that explicitly there).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area:PackageDefinition Resolution:Question This issues appears to be a question, not a product defect WaitingForCustomer Applied when a NuGet triage person needs more info from the OP
Projects
None yet
Development

No branches or pull requests

3 participants