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