Using NuGet Versioning with build number

I’m using Octopus 3, but based on the feature changes, I’m assuming this has nothing to do with Octopus 3 and probably occurs in Octopus 2. If I need to ask this in the Octopus 3 forum, please let me know.

I’m using NuGet’s versioning (https://docs.nuget.org/create/versioning).
It says for an incremental build number, you can make a version like this: 1.2.5-build8. The article states that 1.2.5-build.8 is not supported.

So, my problem comes with Ocotpus determining the most recent release. Suppose after I have 1.2.5-build8 that Ilater add 1.2.5-build10. Octopus still thinks 1.2.5-build8 is the most recent version, probably because it’s a lexicographic search and “8” > “10” is true.

Since NuGet docs mention this notation is acceptable and suggests it for daily or continuous builds, I thought it seemed like a great idea until I realized that Octopus won’t think a newer version is the latest. I suppose I could go to something like 1.2.5-build0001 and that work work, but that seems to contradict SemVer’s idea of no leading zeroes.

Any suggestions on what to do? Or if this is an Octopus bug?

Hi Michael,

Thanks for getting in touch! You’re right, the NuGet specification is more restrictive than SemVer when it comes to version numbering, and we need to fit within the constraints of the NuGet spec. In this situation the NuGet spec states (https://docs.nuget.org/create/versioning): The prerelease versions are given precedence in alphabetical order (well technically lexicographic ASCII sort order).

Since Octopus can use a combination of external NuGet feeds and its own Internal NuGet store we follow the same ordering conventions to maintain the widest possible compatibility. Take a look at the NuGet.Core.SemanticVersion implementation of IComparable: https://github.com/Haacked/NuGet/blob/master/src/Core/SemanticVersion.cs#L243

As further background, we have changed the implementation of our Internal NuGet Store for 3.0 to use SQL Server, and taking a look over the Stored Procedure that handles NuGet Packages I can confirm it also implements lexicographic ASCII sort ordering. (See the procedure called ‘GetNuGetPackages’)

At this point I’d suggest this isn’t a bug in Octopus. Perhaps your best option is to prepend zero’s to the special version as you mentioned. This should have no negative side-effects. I would personally avoid leading zeros for all of the other version numbers (Major, Minor and Build/Revision) as suggested by the SemVer spec.

Just in case you’re using something like git and TeamCity there’s an interesting meta runner that supports GitVersion: https://github.com/JetBrains/meta-runner-power-pack/tree/master/gitversion. This might be an interesting alternative approach.

Hope that helps!
Mike

Thanks. I kind of thought that was the case. I’ll probably go with the leading zeroes for the build number.

Hi Michael,

Thanks for the reply. That sounds like the best compromise given the situation.

Thanks!
Mike