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