Menu
▾
▴
Re: [dotNetRDF-Develop] NuGet Packaging
|
From: Rob V. <rv...@do...> - 2013-04-19 21:10:57
|
Why can't we use the local HG numeric revision? While this isn't unique across clones if we have a single build server responsible for builds that should be irrelevant since it will always increment on that server Rob On 4/19/13 3:50 AM, "Tomasz Pluskiewicz" <tom...@gm...> wrote: >Kal, > >Oh I see. I think I slightly misunderstood the prerelease feature > >So maybe let's do it this way. The current stable release is >0.9.0.2110 and the upcoming is 1.0.0. This means that the automatic >builds would be named > >1.0.0-prerelase2111 >1.0.0-prerelase2112 >1.0.0-prerelase2113 > >and the stable would be just 1.0.0.2114 or simply 1.0.0 at which point >it will be bumped to 1.0.1 for the next batch of prerelease. Would >that be more like whet SemVer is about? > >Regarding tracing back a build to HG revisions. There are some ways. >One would be to include the commit hash in version string (not good >IMO). There's also the VCS labelling feature in TeamCity. I just got >it create a tag in my test repo [1]. The downside is there will be a >swathe of tags but it's super easy to remove tags from time to time as >a cleanup task. > >Tom > >[1]: >https://bitbucket.org/tpluscode/dotnetrdf-teamcity/commits/c1f1ac2c6ab242d >3d104e920b33718a89b2280b5 > >On Fri, Apr 19, 2013 at 10:55 AM, Khalil Ahmed <ka...@ne...> >wrote: >> Hi Tom, >> >> All looks fine to me. Though just to be clear this approach is >>basically not >> making use of the prerelease versioning functionality of NuGet, because >> prerelease versioning in nuget is based on the value after the dash. It >>all >> works nicely though as NuGet will treat a stable 0.9.0.2116 release as >>later >> than a pre-release 0.9.0.2116-nightly130420 release. >> >> Will there be some way to tie build number back to some state of the Hg >> repository ? >> >> Cheers >> >> Kal >> >> >> On Thu, Apr 18, 2013 at 10:11 PM, Tomasz Pluskiewicz >> <tom...@gm...> wrote: >>> >>> Hi >>> >>> There is one other way to proceed with unstable NuGet packages. We can >>> set up TeamCity as a package repository. The downside is that we would >>> have to require users to modify their setup. Having said that I'm too >>> in favour of using the prerelease feature and having only one package >>> stream. In fact I'd forgotten that feature exists. >>> >>> Unfortunately Rob's right and we will need to ensure correct >>> dependencies but it should be fairly easy to achieve using the <style> >>> target of NAnt. Similar to what I have done to patch the Windows Phone >>> csproj. >>> >>> Regarding naming I agree with rob to stick to the current pattern like >>> the 0.9.0.2110 example. I think it would be easiest if the >>> Major.Minor.Patch part could become a TeamCity setting updated >>> manually when we see fit. The build part would be supplied >>> automatically after each build (suceeded or otherwise). The nice thing >>> about TeamCity is that we can have it use that number to patch all >>> AssembyInfo.cs files at once before build. >>> >>> So the build numbers would be 0.9.0.2110, 0.9.0.2111, 0.9.0.2112 and >>> so on. Judging by your suggestions I understand that you would like >>> the prerelease packages uploaded daily (provided anything changed)? My >>> initial idea was to do that after each successful build by it may be >>> an overkill. If so I think the the -nightly{yyMMdd} suffix is a good >>> idea. >>> >>> To sum up we would have a single versioning pattern, and at moment of >>> our choosing we would publish an official NuGet package: >>> >>> build 0.9.0.2112 => prerelease NuGet 0.9.0.2112-nightly130418 >>> build 0.9.0.2115 => prerelease NuGet 0.9.0.2115-nightly130419 >>> build 0.9.0.2116 => prerelease NuGet 0.9.0.2116-nightly130420 >>> >>> At this point we may decied that the last build was good enough and so >>> the same version would be published as a stable NuGet package >>> versioned without the prefix as simply 0.9.0.2116 and the main part >>> could be bumped to 0.9.1. >>> >>> Thougths? >>> >>> Tom >>> >>> On Tue, Apr 16, 2013 at 6:14 PM, Rob Vesse <rv...@do...> >>>wrote: >>> > 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 >>> > >>> > >>>------------------------------------------------------------------------ >>>------ >>> > 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 >>> > >>> > >>> > >>> > >>>------------------------------------------------------------------------ >>>------ >>> > 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 >>> > >>> >>> >>> >>>------------------------------------------------------------------------ >>>------ >>> 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 >> >> >>------------------------------------------------------------------------- >>----- >> 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 >> > >-------------------------------------------------------------------------- >---- >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 |
