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? >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>> >> >
