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