Btw, are there any download stats from the existing CI builds that could tell us whether this is even worth the effort? Obviously having the builds as packages in NuGet is likely to increase consumption of them *somewhat* but what is our existing rate of consumption that we're trying to increase *from* ?
-Steve B. On May 23, 2012 1: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? >>>> >>> >>> >>
