23

Closed

Support for SemVer 2.0 specification's notion of pre-release builds

description

SemVer 2.0 was just released, as announced by Phil Haack, and the major feature is the addition of a specification for build numbers for pre-release packages. It would be great to see NuGet add support for both understanding this from a package building as well as package discovery from feeds.
Closed Sep 24 at 6:49 PM by JeffHandley
Merging into #3924.

comments

JeffHandley wrote Jun 18, 2013 at 7:38 PM

Yes, thanks. We have been working very closely with Phil on getting SemVer 2.0 to reach RTM.

We do still have some important questions to ask, so I'm glad you filed this issue. While I think we can all agree that "Support build numbers" is an important feature request (and I think we have duplicates in the issue list already), we need to understand details of what that actually means.
  1. Can you provide scenarios that you would like to be supported?
  2. Should nuget.org support build numbers in packages?
  3. What behaviors do you expect from NuGet in the VS dialog and PowerShell consoles for handling build numbers?
We understand that the general concept of build number support is important to a lot of people, but before we start adding that support, we need to understand better what scenarios this targets and how it should behave.

Thanks!

dmarsh wrote Jun 18, 2013 at 10:55 PM

Hey Jeff,

Thanks for taking the time. Let's see if I can answer some of those:

1A. So I actually think this MSDN article summarizes a lot of the things that "don't work" well right now because of the lack of support for build numbers, specifically the versioning amongst pre-release packages being impossible.

We very often run into the case where we're working on a couple branches of the same shared package concurrently, so we would like the ability to be able to be able to do something like "Update-Package -Safe" and have "safe" mean it stays within the currently selected pre-release version and only rev out of that if there's a newer build of that pre-release version.

2A. I do not personally need nuget.org itself to support them, but it would be awesome if NuGet Server did since we leverage that to host NuGet packages internally. We are actually actively moving to MyGet, so whatever is decided here will hopefully be adopted by MyGet, but that's obviously out of your realm of concern other than wanting the best thing for the entire NuGet community. :)

3A. So, let's do an example...

Let's say I have MyAwesomePackage.1.0.0 out there. However, I've started up a new sprint and that demands a new pre-release package and so we do something like "MyAwesomePackage.1.1.0-ProjectA.1". Now my apps that want to integrate with that version have referenced that pre-release version and a couple builds go by since they last updated so now let's say there's a "MyAwesomePackage1.1.0-ProjectA.4".

Next the curve ball: let's say another project which was being concurrently developed, call it "ProjectB", just released and has now officially claimed the "MyAwesomePackage.1.1.0" version number because it won the agile race out the door. Today if I do an "Update-Package -Safe" NuGet will take non-pre-release over my pre-release version for "ProjectA" and I'll be in trouble unless I bump my version on the "ProjectA" pre-release to 1.11 or 1.2 or whatever.

With the new SemVer 2.0 rules, what I'd like to see happen is, when I do "Update-Package -Safe" on a project that references a pre-release version, I would want it to stick within the already selected pre-release ("ProjectA") and only consider packages within that pre-release as "safe". I would be ok with having to pass a different or additional arguments to ensure this. Maybe, for example, you would need to combine -Safe and -Prerelease at the same time? That's obviously part of the discussion here.

From the VS dialog perspective, well... that's a great question. I think maybe -Safe behavior should almost always be the default and maybe the VS dialog can actually tell you "hey, you know there's actually a newer version than the pre-release package of MyAwesomePackage that you have now, are you sure you don't want to upgrade to it?"

mavnn wrote Oct 25, 2013 at 12:42 PM

Hi Jeff,
we've recently been bitten by this one when a build number rolled up from 99 to 100.

For all clients and for nuget.org, I would expect to be able to specify any version string that is valid according to the semver v2.0 and have it ordered correctly according to the spec.

This would then imply that from the VS and Powershell clients, if I select safe I would expect the latest released version and if I select pre-release I would get the version that is ordered as the maximum by the criteria in semver. I would also love the ability to install a specific version from the VS plugin, but that's a separate issue.

johncrim wrote Nov 13, 2013 at 11:03 PM

For my company's uses, the biggest missing aspect of SemVer 2.0.0 is support for build metadata - eg
  • 1.1.0-dev+r1111
  • 1.1.0-dev+14
We would use the first to denote a revision number (needed for subsequent prerelease builds on trunk), and the second to denote a build number (when using git and revision numbers aren't available).

jhess001 wrote Dec 2, 2013 at 3:30 AM

Agreed, looking forward to getting support for build metadata.

manuel4y wrote Jan 29 at 5:48 PM

+1

juste wrote Aug 7 at 8:55 PM

NuGet.Versioning supports SemVer 2.0.0. It is currently used in the NuGet v3.0.0 shim, but NuGet Core still replies on an older implementation of SemVer. In the nearish future the core will start using the NuGet.Versioning package also.