This project is read-only.


Nuget should allow versions like 2.1-alpha.10



at the moment it's not possible to create version numbers like 2.1-alpha.10 (see - they use them too) instead we have to use 2.1-alpha10. But then nuget sorts these version alphabetically which means 2.1-alpha10 is treated as older than 2.1-alpha9. (I was told by @dotnetjunky on twitter that this is not a bug.)

At the moment I have no other choice than to use versions like 2.1.9-alpha and 2.1.10-alpha which are treated in the right order. But this seems to conflict semver.

Closed Jan 26, 2013 at 5:20 PM by dotnetjunky


dotnetjunky wrote Jan 25, 2013 at 8:54 PM

This is a dupe of #1796

** Closed by dotnetjunky 01/25/2013 12:54PM

forki wrote Jan 25, 2013 at 10:05 PM

hey dotnetjunky,

this is a real issue for people with CI builds. 10 builds is not that big number.


forki wrote Jan 25, 2013 at 10:12 PM

I don't want you to implement SEMVER fully like #1796 suggest. I just want to nuget to support more than 9 prerelease packages. I think this is not a duplicate.

pranavkm wrote Jan 25, 2013 at 10:41 PM

@forki, you could always pad earlier builds. 2.1-alpha009 would work just as effectively as your alternate mechanism of using build numbers. Once SemVer RTMs, the team's planning on adding support for it, so it shouldn't be a problem

forki wrote Jan 25, 2013 at 11:30 PM

@pranavkm Really!? Is this your solution?

forki wrote Jan 25, 2013 at 11:33 PM

[Sorry. Shouldn't sound that harsh. Why can't I edit this comment?]

The problem with 0009 is that the version no. is retrieved from a build server which also has to support this. Which some don't.

dotnetjunky wrote Jan 26, 2013 at 5:20 PM

We suggest you update your build script to pad 0's in front of the build number to produce the desired nuget version. As pranavkm said, we're planning to support SemVer RTM, which will address your situation. Until then, we really don't want to add any stop-gap solution.