8

Closed

Support semver >= 2.0.0-rc.1 specification

description

Please add support for the semver 2.0.0-rc.1 specification on semver.org
Closed Jan 14 at 4:22 PM by howarddierking
We're working with the semver folks to drive the spec to 2.0.0 and will support the stable version.

comments

dotnetjunky wrote Sep 26, 2012 at 2:51 PM

why do you need here?

dotnetjunky wrote Sep 26, 2012 at 2:56 PM

Typo. I meant to ask: "why do you need it?"

manuel4y wrote Sep 26, 2012 at 3:44 PM

I have an ci/dev environment here, that handle the versioning with the 2.0.0-rc.1 specs.
The nuget build step can't executed with version like 1.0.0-beta.1 or 1.0.0+build.ci.3.abcdef

manuel4y wrote Sep 26, 2012 at 4:24 PM

I had reimplemented the semanticversion class for strict semver 2.0.0-rc.1 in the corelib. Is this helpfull?

dotnetjunky wrote Sep 26, 2012 at 5:12 PM

You can easily achieve the same result by settings your version as: 2.0.0-rc_1. Does this work for you?

manuel4y wrote Sep 26, 2012 at 5:53 PM

Is ok, i insert a pre-build-step that normalize the version (1.0.0-build.1 -> 1.0.0-build1 or 1.0.0+build.ci.cp.1 -> 1.0.0+build-ci-cp1).
But the complete support for semver 2.0.0 would be awesome...

XavierDecoster wrote Sep 26, 2012 at 6:05 PM

The real issue I think is the way the sorting is done (lexicographic ASCII) on the prereleasetag, which is why considering the latest SemVer spec would be useful.

rc_1 < rc_10 < rc_2

This causes rc_2 to look newer than rc_10, which is wrong.
That's why the only way to achieve this at the moment is to ensure you use leading zeros, always have the same amount of numeric characters, and decrement the amount of leading zeros when required.

e.g.

rc_001 < rc_002 < rc_010

I also explain these findings in this article: http://www.developerfusion.com/article/144809/continuous-integration-using-nuget-and-teamcity/

dotnetjunky wrote Sep 26, 2012 at 6:18 PM

Yes, you're right, but adding leading 0's doesn't look so bad, does it?

I'm reluctant to make any more change to the SemanticVersion class because it would require a lot of testing to make sure existing packages work well with the new scheme. And I'm sure there'll be unexpected bugs/oddities popping up with the extra build number component in version.

In conclusion, I don't think there's enough bangs for the bucks to add this support.

XavierDecoster wrote Sep 26, 2012 at 6:41 PM

Yep, know what you mean, not exactly a quick win, potentially risky and high cost, SemVer still not RTM etc...

On the other hand, the average Joe will not think of this and will have a hard time creating auto-incrementing pre-release packages. Trying to get this system with leading zeros into place is even a whole different story depending on the build system and available knowledge... I know this is in fact blocking some people from using NuGet.

So I still hope it pops up on the radar one day ;)

dotnetchris wrote Nov 9, 2012 at 5:50 PM

I came here to file an issue that -alpha10 is not considered newer than -alpha9 according to nuget. This issue seems to acknowledge that.

Sign in to add a comment