[dotNetRDF-Develop] NuGet Packaging

[Rob V. <rv...@do...>]

Hey All

This email is part information sharing on how I currently package and upload
dotNetRDF for NuGet but also to start a discussion on the possibility of
making unstable builds available via NuGet which would make it easier for
users to consume and verify bug fixes.

Packaging

Currently packaging is done via pre-build NuSpec files and NAnt targets.
Under Build/nuget/ in the repo you will find a sub-directory for each
package we produce.  In a clean repo this will contain only a .nuspec file
and possibly a readme.txt if the package requires one.

To generate the NuGet packages use NAnt and one of the following targets:

* dist-libs-nuget ­ Builds all the NuGet packages
* dist-libs-nuget-core ­ Build the core library package
* dist-libs-nuget-data-virtuoso ­ Build the Data.Virtuoso package
* dist-libs-nuget-query-fulltext ­ Builds the Query.FullText package
These targets rely on various other targets so will compile things as
necessary.

Uploading

Uploading the releases is done via NAnt, the equivalent NAnt targets for the
aforementioned targets simply replace dist with upload in the target name.

Publishing Nightly Builds

Tom has suggested that as part of getting our CI infrastructure properly
spun up we should push out nightly builds to NuGet automatically.  Currently
the only means we have for distributing nighties is via the binaries-nightly
repo we maintain at SourceForge which relies on a developer manually
uploading a new build.

The main barrier to this with NuGet as I understand it is that unlike
Java/Maven where you can specify SNAPSHOT on the end of your version and
have the server generate unique version numbers for you with NuGet you have
to specify a unique version number each time.  So we need some mechanism to
inject version numbers into the nuspec files, NuGet does appear to support
placeholders but we would need to test to make sure these work as described.
We would also need to make sure that if we take this approach that we are
using * in the build field of our AssemblyVersion attributes so that we get
an incrementing version number.

The other issue is where to publish these, we can either publish to a
separate package ID which is explicitly described as Nightly/Unstable or we
can publish unstable releases directly to the main feeds using the NuGet
pre-release functionality
(http://docs.nuget.org/docs/reference/versioning#Prerelease_Versions)

There are arguments for both approaches:
* Separate package separates more cleanly from stable releases BUT
introduces noise into NuGet search results unless we only publish
pre-release builds to the unstable channel (pre-release builds are hidden by
default from search results)
* Separate package allows us to have a package with more owners so any
developer can publish to it, same package means expanding owner list
* Publishing pre-release versions avoids having to have separate packages
for every package we have (currently 3)
* Publishing pre-release versions makes it easier for NuGet users to switch
their dependency to the nightly build without changing their package
dependencies.
Thoughts and suggestions in this area are welcome,

Rob