0

I'm using Nuget 4.3.0.4406 to pack an assembly with version 5.2.29.181212.8244-RC but I get

2018-12-12T08:44:02.8053309Z ##[error]The nuget command failed with exit code(1) and error('5.2.29.181212.8244-RC' is not a valid version string. Parameter name: value)

The versioning is NOT semver compliant but Nuget puts on restrictions and it's not clear which..? Does this mean Nuget not just supports SemVer but enforces it? I found this but I'm not sure what they mean with the SpecialVersion?

Basically I just want x.y.z.[date+buildid](-rc) where x.y.z are tied to a specification version so it can not be ommitted (we don't own that versioning).

Update

  • 9.9.9.1812129999-rc works but 9.9.9.18121299999-rc and 9.9.9.9812129999-rc don't, where is this specified? (it's a numeric size limitation not a string length)
grmbl
  • 2,514
  • 4
  • 29
  • 54
  • 1
    NuGet's [NuGetVersion code is here](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Versioning/NuGetVersion.cs). You can see the constructors take `int`s, hence any value you put in the numeric part of the version needs to fit in an `int`. If the error message isn't clear, you could (report an issue)[https://github.com/NuGet/Home/issues] so they can improve the error message in this scenario. – zivkan Dec 12 '18 at 15:21
  • thanks, I was actually searching for that earlier :) – grmbl Dec 12 '18 at 15:45

1 Answers1

2

Taken from the NuGet Package Versioning Reference on Microsoft Docs:

With NuGet 4.3.0+ and Visual Studio 2017 version 15.3+, NuGet supports Semantic Versioning 2.0.0.

Certain semantics of SemVer v2.0.0 are not supported in older clients. NuGet considers a package version to be SemVer v2.0.0 specific if either of the following statements is true:

  • The pre-release label is dot-separated, for example, 1.0.0-alpha.1
  • The version has build-metadata, for example, 1.0.0+githash

For nuget.org, a package is defined as a SemVer v2.0.0 package if either of the following statements is true:

  • The package's own version is SemVer v2.0.0 compliant but not SemVer v1.0.0 compliant, as defined above.
  • Any of the package's dependency version ranges has a minimum or maximum version that is SemVer v2.0.0 compliant but not SemVer v1.0.0 compliant, defined above; for example, [1.0.0-alpha.1, ).

Of course you can find the Semmantic Versioning Specification at semver.org. I think you're especially interested in spec-item10:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

Your version would become something like x.y.z(-rc)+[date+buildid]

rickvdbosch
  • 14,105
  • 2
  • 40
  • 53
  • Hey @rickvdbosch, that's not what we want, the version should have both x.y.z (the spec version) and the date+buildid (that's what WE own). It's not relevant to the pre-release part. – grmbl Dec 12 '18 at 09:15
  • Have a look at my updated answer: spec-item10 gives you room to add metadata like in the example at the end of my answer: `x.y.z(-rc)+[date+buildid]` – rickvdbosch Dec 12 '18 at 09:25
  • I'm aware of the metadata but `Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence.` – grmbl Dec 12 '18 at 09:29
  • you could put the date as the prerelease label, which I would argue fits better with SemVer's design/goals. – zivkan Dec 12 '18 at 15:16
  • 1
    or if you don't use the 3rd segment, split the date from the time and use `x.y.date.time+metadata`, although that strictly isn't semver and relies on a quirk of NuGet's implementation since they need to also support `System.Version` style `a.b.c.d` versions. – zivkan Dec 12 '18 at 15:17