[SPRNET-1508] Publish pre-release versions to NuGet Created: 04/May/12  Updated: 21/May/12  Resolved: 10/May/12

Status: Resolved
Project: Spring.NET
Affects Version/s: 1.3.2
Fix Version/s: 2.0 M1

Type: Task Priority: Minor
Reporter: Marijn van der Zee Assignee: Steve Bohlen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


NuGet supports semantic versioning, which allows to publish packages like "Spring.Web.Mvc4-alpha1", where every package with a version number ending in dash+somestring is considered a pre-release version.

This would be useful, because it allows developers to quickly test new features and fixes by doing a simple NuGet install into their project.

We might even go as far as to publish a package for each build; NServicebus amongst others does this: http://nuget.org/packages/NServiceBus-CI.

Comment by Steve Bohlen [ 04/May/12 ]

I concur. We've been waiting for this NuGet feature since just about when NuGet was first announced/released. At a minimum we should modfiy the build-script to support adding an arbitrary suffix to the nuget package version numbers when they are assembled as part of the build.

re: automating the release of packages based on the nightly CI build, one intersting difference we need to consider betw. NSB and SPRNET is the sheer number of packages we have. This isn't an issue re: publishing them b/c we can obv. automate that from the CI server but I wonder if there's actually the need to do what NSB has done here and actually create a whole sep. package to represent the CI build (e.g., NServiceBus-CI).

It seems somewhat unnecessary to me to have separate Spring.Core.CI, Spring.Aop.CI, Spring.Web.CI, etc. packages if we also have the ability to do pre-release semantic versioning of the existing packages. However, there might be a distinction between 'nightly build' and 'pre-release' that we want to reinforce and sep. packages for nightly builds would help cement this disctinction.

We should probably consider which of the following two strategies makes the most sense:

a) Publish separate packages from the CI server (also using semver to distinguish them as pre-release). This would require someone to explicitly select the Spring.Core.CI package from nuget distinct from the Spring.Core package and presumably to then remove the Spring.Core.CI package and replace it 'manually' with Spring.Core at some later point. Because of the sheer number of packages that might be in use from SPRNET, this isn't as trival as removing the single NSB-CI package and replacing it with the main NSB package so we need to consider this approach carefully IMO. In this scenario, the distinction between 'pre-release' and 'nightly CI build' versions of SPRNET is maintained.

b) Update the existing packages from the CI server (also using semver to distinguish them as pre-release). This would permit the user to leverage the 'show me latest vs show me only released' setting in the nuget package manager and to rely entirely upon that distinction to select which they want. In this scenario, there is no disctinction between 'pre-release' and 'nightly CI build' version of SPRNET packages.

Comment by Marijn van der Zee [ 04/May/12 ]

I'd prefer option b).

NServicebus publishes quite some packages too, with a matching CI package. I'm not sure why they do this as I don't really see the advantage either. I posted to their newsgroup to ask. An advantage I do see is that the non-CI package list is clean:

PM> get-package -listavailable -filter nservicebus -allversions

Id                             Version            
--                             -------

NServiceBus                    3.0.0                                                    
NServiceBus                    3.0.1                    
NServiceBus                    3.0.2                    
NServiceBus                    3.0.3

Opposed to:

NServiceBus-CI                 3.0.1881                 
NServiceBus-CI                 3.0.1882
... + 0.0.1  
NServiceBus-CI                 3.0.2216

Which adds up to hundreds of lines of releases.

Comment by Steve Bohlen [ 04/May/12 ]

Its also possible that the use of NSB-CI is a left-over from before nuget supported pre-release versions. I'd be quite interested to hear their reasoning behind their approach before we select one of these two options, since there are pros and cons to both choices. In the mean time, I am already proceeding to create the mods to the build script to support appending a suffix on the version number for the nuget package (which obv. needs to be done either way).

Comment by Steve Bohlen [ 04/May/12 ]

BTW, there is also an option C that's probably worth considering as well: use a totally separate nuget feed for the CI nightly builds. This would mean that the official nuget.org feed would be for released versions and specific pre-release milestones (e.g., alpha, beta, M0, M1, RC, whatever) but if someone wanted the nightly build they would have to explicitly configure their nuget client to point to an additional feed source (either hosted by ourselves or more likely something like http://http://www.myget.org/). This option is certainly much less discoverable, but would still permit us to retain the distinction between 'nightly builds that just happen to pass all their tests'' and 'official pre-release milestones' which are (presumably) passing through a higher quality of release-gate before going out the door.

Comment by Marijn van der Zee [ 04/May/12 ]

I posted in a reply to this thread: http://tech.groups.yahoo.com/group/nservicebus/message/12013.
But my reply isn't visible yet.

Comment by Steve Bohlen [ 04/May/12 ]

That post on the NSB mailing list definitely pre-dates the support for pre-release packages in nuget. Will be interested to see if they are considering using the support for semver and pre-release packages in nuget now that its formally supported or if they see value in retaining the CI-built packages separately. One reason to (perhaps) discount option B that the nighlty builds happen (by definition <g>) every night and so dumping them into the main nuget feed would literally mean that everyone who has 'show pre-release packages' checked would start their every day with a potential 'new' package to update whether or not there were any actual changes to the codebase at all in that package!

Comment by Marijn van der Zee [ 05/May/12 ]

Indeed nsb did this prior to pre release funtionality of nuget, see Andreas' reply at the nab newsgroup. It also appears that the nuget team is considering some sort of build release support in nuget: https://github.com/mojombo/semver/issues/20 and http://haacked.com/archive/2011/10/24/semver-nuget-nightly-builds.aspx.

Comment by Steve Bohlen [ 10/May/12 ]

The infrastructure changes for this (build-scripts, nuspec metadata, etc.) are all complete. Passing the following additional param to NANT will now result in the assemblies and the packages all receiving the desired pre-release suffix ("M0" in this example):

-D:package.version=2.0.0 -D:nuget.version.suffix=M0

This results in packages that are assembled as follows:


All SPRNET package inter-dependencies are also configured to state a dependency on the correlated pre-release packages (e.g., Spring.Aop.2.0.0-M0.nupkg depends on Spring.Core.2.0.0-M0.nupkg) so the assumption is that all packages from a single pre-release 'group' will be rev-ed together at the same time (same assumption already in place for the regular-release packages).

Note: since nuget's pre-release versioning respects alphabetical order, using a strategy of M0, M1, M2, M3, M# should guarantee that later milestone releases are properly 'seen' by nuget as being later versions for the purposes of package dependency resolutions (i.e., we will NOT be using an 'alpha1', 'alpha2', 'beta1', 'beta2', etc. approach).

We can now push pre-release packages to nuget by invoking the <prj-root>\nuget-packages\push-all-to-nuget.cmd batch file after the build script has been run to create the assemblies and package them up as usual.

NOTE: the closure of this issue still leaves unresolved the related decisoon re: whether (or not) to wire up automatically pushing nuget packages as part of the regular CI nightly build process.

Comment by Marijn van der Zee [ 21/May/12 ]

Nice work.

IMO it would be best to publish M1, M2 ... release to NuGet.org (as now is the case) and have a separate feed for integration builds, as you proposed above. This way, the "public" spring.net feed stays clean, as opposed to the (somewhat confusing) NServiceBus-CI style packages.

The Team City integration service supports this out-of-the box (http://blogs.jetbrains.com/teamcity/2011/11/24/new-teamcity-7-0-eap-build-20702/). Maybe the Bamboo does so too, or will do in the feature?

Generated at Sat Jul 20 03:02:59 UTC 2019 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.