Menu
▾
▴
dotnetrdf-develop
|
From: Rob V. <rv...@do...> - 2013-04-15 21:08:29
|
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 |
|
From: Khalil A. <ka...@ne...> - 2013-04-16 08:22:04
|
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
|
|
From: Rob V. <rv...@do...> - 2013-04-16 16:15:43
|
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
|
|
From: Tomasz P. <tom...@gm...> - 2013-04-18 21:12:11
|
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
>
|
|
From: Khalil A. <ka...@ne...> - 2013-04-19 08:55:31
|
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
|
|
From: Tomasz P. <tom...@gm...> - 2013-04-19 10:51:04
|
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/c1f1ac2c6ab242d3d104e920b33718a89b2280b5 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 > |
|
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 |
|
From: Tomasz P. <tom...@gm...> - 2013-04-19 21:38:25
|
Numeric revision numbers aren't available on TeamCity. There is no way to view which revision such local number actually represents. I'm not even sure how TeamCity organizes it's local repositories. And if you add multiple build agents to the mix it becomes even more tricky and misleading. Tom On Fri, Apr 19, 2013 at 11:10 PM, Rob Vesse <rv...@do...> wrote: > 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 > > > > > > ------------------------------------------------------------------------------ > 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X