Re: [dotNetRDF-Develop] NuGet Packaging

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

The build number can be used as part of the version string still, currently
the Core library package uses version 0.9.0.2110 which works fine

I like the notion of applying ­nightly{YYMMDD} as the pre-release string, it
is nice and clean and does not involve having separate unstable packages

The other thing we need to worry about is getting dependencies right across
the packages since the Virtuoso and FullText libraries rely on the core
library.

Rob

From:  Kal Ahmed <ka...@ne...>
Reply-To:  dotNetRDF Developer Discussion and Feature Request
<dot...@li...>
Date:  Tuesday, April 16, 2013 12:58 AM
To:  dotNetRDF Developer Discussion and Feature Request
<dot...@li...>
Subject:  Re: [dotNetRDF-Develop] NuGet Packaging

> Hi,
> 
> One problem with NuGet versioning is that they have chopped off the build
> number, which means that if we have separate unstable packages we potentially
> have issues in keeping the unstable package version and the stable package
> version properly aligned.
> 
> It looks like NuGets pre-release versioning uses the last string part of the
> package version to order packages from oldest to newest. So if we went for
> publishing pre-release versions we could use a scheme like
> {maj}.{min}.{patch}-nightly{YYMMDD} e.g. 1.0.1-nightly130416. This way all
> nightly builds for a given release level stay in the correct order with the
> 1.0.1 release build being considered newer than all 1.0.1-nightlyXXXXXX
> builds.
> 
> For those reasons, I think that to start with using NuGet pre-release
> versioning makes sense - it still leaves us the option of introducing
> "unstable" packages later.
> 
> Cheers
> 
> Kal
> 
> 
> On Mon, Apr 15, 2013 at 10:07 PM, Rob Vesse <rv...@do...> wrote:
>> 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
>> 
>> 
----------------------------------------------------------------------------->>
-
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> _______________________________________________
>> dotNetRDF-develop mailing list
>> dot...@li...
>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>> 
> 
> 
> 
> -- 
> Kal Ahmed
> Director, Networked Planet Limited
> e: kal...@ne...
> w: www.networkedplanet.com <http://www.networkedplanet.com>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced analytics
> on semi-structured data. The platform includes APIs for building apps and a
> phenomenal toolset for data science. Developers can use our toolset for easy
> data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter______________________
> _________________________ dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop