As long as the timeouts can be solved, the symbols are always useful... Diego
On Thu, May 24, 2012 at 1:23 AM, Julian Maughan <[email protected]>wrote: > It would certainly be good to automate the build of the NuGet package on > the CI server - whether or not its published doesn't bother me. > > Would we want to deploy the symbols as well? Reason I ask is that there > have been difficulties (timeouts) uploading them. > > > On 24 May 2012 03:57, Diego Mijelshon <[email protected]> wrote: > >> Zeroes is probably best. But we'd have to try. >> >> >> On Wed, May 23, 2012 at 4:48 PM, Stephen Bohlen <[email protected]>wrote: >> >>> I guess so long as its also a separate package from the release package >>> this might be feasible. So we'd have something like... >>> >>> NHibernate-AutomatedBuild.2012.0523.1545.nupkg (May 23rd, 2012 at 15:45) >>> NHibernate-AutomatedBuild.2012.0524.0822.nupkg (May 24th, 2012 at 08:22) >>> >>> It begs the question though: what version do you stamp the actually >>> assembly with? 0.0.0? Or one of the above (2012.0524.0822)? >>> >>> >>> >>> Steve Bohlen >>> [email protected] >>> http://blog.unhandled-exceptions.com >>> http://twitter.com/sbohlen >>> >>> >>> On Wed, May 23, 2012 at 3:13 PM, Diego Mijelshon <[email protected] >>> > wrote: >>> >>>> Yes, that's what I meant. 0.0.0 might work... or we could use YYYY as >>>> major, MMDD as minor, HHMMSS as revision... or anything else. >>>> It really doesn't matter much, as the idea is to use whatever is the >>>> latest successful build. >>>> >>>> Diego >>>> >>>> >>>> On Wed, May 23, 2012 at 4:10 PM, Stephen Bohlen <[email protected]>wrote: >>>> >>>>> Sorry I think I misunderstood your point -- I just reread your >>>>> message. So you mean that we don't need the 3.0.0 part and could just do >>>>> the YYYYMMDDHHMMSS part of the version? >>>>> >>>>> I suppose this might work, but then we'd need to have *something* in >>>>> the version slots to make NuGet happy (e.g., at least 0.0.0) else I don't >>>>> think its version-composing algorithm will work properly. >>>>> >>>>> Was that more what you meant...? >>>>> >>>>> -Steve B. >>>>> On May 23, 2012 2:04 PM, "Stephen Bohlen" <[email protected]> wrote: >>>>> >>>>>> No? Since you can't replace the contents of an existing NuGet >>>>>> package without increasing its version number, how would that work? How >>>>>> would you distinguish the latest automated build result from the one 10 >>>>>> minutes prior? >>>>>> >>>>>> Are you envisioning that we would script the complete removal of the >>>>>> existing package and then post a brand new package named/versioned >>>>>> identically to the one just deleted? And if a don't increment the >>>>>> version, >>>>>> clients doing an update operation to get latest won't see anything new >>>>>> because NuGet depends on version-comparisons to work, no? >>>>>> >>>>>> -Steve B. >>>>>> On May 23, 2012 1:59 PM, "Diego Mijelshon" <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> You don't even need the version part. It's just continuous delivery. >>>>>>> >>>>>>> Diego >>>>>>> >>>>>>> On Wed, May 23, 2012 at 3:23 PM, Stephen Bohlen >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> So were leaning towards something like.... >>>>>>>> >>>>>>>> NHibernate-AutomatedBuild.3.0.0-YYYYMMDDHHMMSS.nupkg >>>>>>>> >>>>>>>> ...so we can ensure both uniqueness and proper version sort order >>>>>>>> (assumes impossible to build twice in the same second!). Is that >>>>>>>> right...? >>>>>>>> >>>>>>>> -Steve B. >>>>>>>> On May 23, 2012 1:18 PM, "Diego Mijelshon" <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> A separate feed is what Microsoft itself is doing with MVC4 (see >>>>>>>>> http://blogs.msdn.com/b/henrikn/archive/2012/04/29/using-nightly-nuget-packages-with-asp-net-web-stack.aspx >>>>>>>>> ) >>>>>>>>> >>>>>>>>> I personally think using a separate package is enough, although >>>>>>>>> naming should be done carefully. NHibernate-CI might not be enough for >>>>>>>>> everyone. >>>>>>>>> >>>>>>>>> Other than that, I really like the idea. >>>>>>>>> >>>>>>>>> Diego >>>>>>>>> >>>>>>>>> On Wed, May 23, 2012 at 12:17 PM, Stephen Bohlen < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> There seems to be little if any consensus about the 'right' way >>>>>>>>>> to do this. NuGet now does support the idea of pre-release packages >>>>>>>>>> (e.g. >>>>>>>>>> something like 3.0.0-alpha as version number) and the ability to >>>>>>>>>> filter >>>>>>>>>> these IN or OUT of the search results in the NuGet client dialog but >>>>>>>>>> the >>>>>>>>>> idea of every CI build showing up as a pre-release version of the >>>>>>>>>> same NH >>>>>>>>>> package that would eventually become the release has some challenges: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. pre-release packages use alpha-numeric sorting to >>>>>>>>>> determine 'latest' by version so while 3.0.0-beta would be >>>>>>>>>> properly newer >>>>>>>>>> than 3.0.0-alpha (since B after A), determining a suffix for >>>>>>>>>> *every* CI >>>>>>>>>> build that ensures that the proper 'latest' pre-release is always >>>>>>>>>> seen by >>>>>>>>>> nuget as 'latest' isn't trivial (we could do something like >>>>>>>>>> 3.0.0-ci-000001, 3.0.0-ci-000002, 3.0.0-ci-000003, etc. but >>>>>>>>>> that's probably >>>>>>>>>> a bit obtuse for people to understand what's going on and in any >>>>>>>>>> case we'd >>>>>>>>>> quickly run out of digits unless we did something silly like >>>>>>>>>> 3.0.0-ci-0000000000000000000000000000001 ) >>>>>>>>>> 2. IMO there is (probably) a difference betw. a) people who >>>>>>>>>> will only want to use the official release, b) people who are >>>>>>>>>> willing to >>>>>>>>>> use 'official pre-release milestones' like alpha, beta, whatever, >>>>>>>>>> and c) >>>>>>>>>> people who really want to live on the bleeding edge of 'every CI >>>>>>>>>> build'. >>>>>>>>>> NuGet's pre-release versioning strategy distinguishes betw. a) >>>>>>>>>> and b) but >>>>>>>>>> NOT betw. b) and c). "Muddying" the distinction betw. b) and c) >>>>>>>>>> for us >>>>>>>>>> would mean that it would no longer be possible to use nuget's >>>>>>>>>> pre-release >>>>>>>>>> versioning to actually release something like 3.0.0-alpha and >>>>>>>>>> have it >>>>>>>>>> appear as 'latest pre-release' b/c it wouldn't be 'after >>>>>>>>>> 3.0.0-ci-0000X. >>>>>>>>>> Creatively considering the suffixing strategy might permit this >>>>>>>>>> to still >>>>>>>>>> work, but its non-trivial to reason through. Worse, even if we >>>>>>>>>> were to do >>>>>>>>>> something clever with suffixes that solved this problem we'd need >>>>>>>>>> to >>>>>>>>>> consider how to handle the situation where we put out >>>>>>>>>> 3.0.0.-special-suffix-for-beta and then someone commits and the >>>>>>>>>> CI process >>>>>>>>>> publishes something that suddenly appears LATER than >>>>>>>>>> 3.0.0-special-suffx-for-beta. This would make it more >>>>>>>>>> challenging for >>>>>>>>>> those seeking the beta to find it since it wouldn't any longer be >>>>>>>>>> 'latest'. >>>>>>>>>> >>>>>>>>>> All of these limitations re: the design/impl of nuget's >>>>>>>>>> pre-release versioning scheme lead me to conclude that using it for >>>>>>>>>> CI >>>>>>>>>> builds is too much of a problem (both for package authors and for >>>>>>>>>> package >>>>>>>>>> consumers). FWIW, I've done considerable investigation into this in >>>>>>>>>> the >>>>>>>>>> context of other OSS projects with CI builds and have concluded that >>>>>>>>>> the >>>>>>>>>> only feasible strategy for publishing CI-build-based packages to >>>>>>>>>> nuget is >>>>>>>>>> one of the following: >>>>>>>>>> >>>>>>>>>> 1. Create your own sep. NuGet feed (either self-hosted or >>>>>>>>>> something like myget.org) and post CI-build-based packages >>>>>>>>>> there; those that want 'bleeding edge' add this second feed to >>>>>>>>>> their nuget >>>>>>>>>> client; those that don't can still distinguish betw. pre-release >>>>>>>>>> milestone >>>>>>>>>> versions (alpha, beta, etc.) and actual release versions in the >>>>>>>>>> main nuget >>>>>>>>>> feed >>>>>>>>>> 2. Create a completely separate package entirely (e.g., >>>>>>>>>> NHibernate-CI.nupkg vs. NHibernate.nupkg) that represents the >>>>>>>>>> CI-build-based content and still push this 'second' package to >>>>>>>>>> the main >>>>>>>>>> nuget feed. >>>>>>>>>> >>>>>>>>>> #1 is less discoverable but since you can filter by nuget feed >>>>>>>>>> source in the Nuget dialog box its then possible for a consumer to >>>>>>>>>> explicitly select the CI-only feed when they want to add/update the >>>>>>>>>> package >>>>>>>>>> based on CI build and then select the main nuget feed only when they >>>>>>>>>> want >>>>>>>>>> to see either/or pre-release milestone packages or the final release >>>>>>>>>> packages. >>>>>>>>>> >>>>>>>>>> #2 is more discoverable since its in the main feed (and would >>>>>>>>>> presumably contain the name 'NHibernate' as part of its package name >>>>>>>>>> so it >>>>>>>>>> would appear in the search results) but it has another challenge: if >>>>>>>>>> its a >>>>>>>>>> DIFFERENT package entirely, then when the main package goes 'GA' >>>>>>>>>> (release) >>>>>>>>>> consumers of the NHibernate-CI package will have NO WAY OF KNOWING >>>>>>>>>> b/c they >>>>>>>>>> won't be using the main NHibernate.nupkg in their projects at that >>>>>>>>>> point >>>>>>>>>> (and doing a nuget-update-packages won't pull down the 'official >>>>>>>>>> release' >>>>>>>>>> at that point b/c they aren't using that actual package at all). >>>>>>>>>> >>>>>>>>>> If there are other ideas about the best way to handle this, then >>>>>>>>>> I am *absolutely* interested in hearing about them since this is a >>>>>>>>>> non-trivial set of issues to grapple with and I continue to seek the >>>>>>>>>> best >>>>>>>>>> possible approach that might be out there (for NH as well as other >>>>>>>>>> .NET OSS >>>>>>>>>> projects that have this exact same set of challenges to exposing >>>>>>>>>> their CI >>>>>>>>>> builds as NuGet packages). >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Steve Bohlen >>>>>>>>>> [email protected] >>>>>>>>>> http://blog.unhandled-exceptions.com >>>>>>>>>> http://twitter.com/sbohlen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, May 23, 2012 at 10:30 AM, Alexander I. Zaytsev < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all. >>>>>>>>>>> >>>>>>>>>>> I think that it would be greate if our CI-builds would be >>>>>>>>>>> available at the nuget. >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>> >> >
