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