Four part version with metadata for non-master builds for NuGet packages on CI
robdmoore opened this issue · comments
I think it would be useful to have a version that contains the four part version along with the tag if present so that you can point to a NuGet repository and have to specify -Pre to get packages from a pull request (also means those packages don't have the same version number as a master build).
e.g.
3 commits after 1.0:
master => 1.0.0.3
pullrequest20 => 1.0.0.3-pullrequest20
alpha => 1.0.0.3-alpha
Thoughts?
I think the NuGet package should have the 3 part version, only the AssemblyVersion and AssemblyFileVersion should be 4 part, and I think the 4th part should always be a 0.
Only reason to have .3 is if you want your CI to expose packages and be able to upgrade to packages between releases. Ideally if you want a new package to be available, you release it, then it all works :)
Only reason to have .3 is if you want your CI to expose packages and be able to upgrade to packages between releases.
Yep - that's exactly what I want. I want someone to be able to point at TC and get the bleeding edge at any time.
Given NuGet supports a 4-part version number it doesn't bother me if there is a fourth number when I push to NuGet - I'm still following semver and if you look at the first three numbers in the version on NuGet then it will still follow semver rules.
Fair nuff, makes sense
Isn't the fact that NuGet supports a 4 part version number part of the larger issue? Semantic versioning only has 3 parts, no?
Yep so we treat the fourth number as metadata - it has no semantic meaning, but is used to make sure that each build has a unique nugget package number so if you point at the build servers nuget repository to get the bleeding edge before it's published to nuget then you can have the latest.