NuGet depends on the presence of a 'string' (suffix) for the version number to distinguish pre-release from release (e.g., 2.0.0-something is pre-release and 2.0.0 is release). This precludes the use of 'pure numbers' to represent non-release packages. We can debate the merits of this but its how it works today.
Either way, I still maintain that there are indeed three groups of consumers out there: release-only, stable-milestone pre-release, and regular-ci-build people, even in the 'current age of CI'. Many people will try a beta or RC in their project to get a sense of pending breaking changes coming their way but aren't going to 'bother' to update to a regular CI build at random points during NH's development process just in order to see what might be going on with the project at an arbitrary point in time, regardless of whether we point out "hey -- its safe, all the tests are green!" :) If we use a completely separate package (NHibernate-AutomatedBuild.XXXXX.nupkg) then the need to use an alpha suffix to flag pre-release is somewhat mitigated, but it still becomes challenging for people who find these bins floating in the wild (e.g., how does one know that 3.0.0.212 is stable but 3.0.0.213 isn't?). There is a package-versioning question that needs to be answered as well as a binary versioning question that needs to be answered. Since the bins cannot have a version that contains alpha characters (but can have a VersionInfo that contains characters) there is some thinking we need to do about how to best correlate the following: - nuget package version (can contain char suffix) - version of the bin(s) in the package (cannot contain char suffix) - versioninfo of the bin(s) in the package (can contain char suffix) Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Thu, May 24, 2012 at 8:36 AM, Oskar Berggren <[email protected]>wrote: > A couple of points: > > Is the scheme of alpha/beta/candidate relevant with CI and in the year of > 2012? > > > Since Teamcity can generate build numbers in various formats, for instance > x.y.z.w > with w being automatically incremented for each build, we could set it > to e.g. 4.0.0.{counter} and then reset the counter when we manually > update the first part. > > We could thus have automatic builds: > > 4.0.0.1 > 4.0.0.2 > ... > 4.0.0.317 (bless this release as GA for those that need longer term > stability) > 4.0.0.318 (update to stable release) > > 4.1.0.1 (next CI build from master) > 4.1.0.2 > etc. > > > The version numbers in CI builds and "long term builds" would then > still have some relation to each other. > > > > > > > 2012/5/24 Diego Mijelshon <[email protected]>: > > As long as the timeouts can be solved, the symbols are always useful... > > > > Diego > > > > > > On Thu, May 24, 2012 at 1:23 AM, Julian Maughan < > [email protected]> > > wrote: > >> > >> It would certainly be good to automate the build of the NuGet package on > >> the CI server - whether or not its published doesn't bother me. > >> > >> Would we want to deploy the symbols as well? Reason I ask is that there > >> have been difficulties (timeouts) uploading them. > >> > >> > >> On 24 May 2012 03:57, Diego Mijelshon <[email protected]> wrote: > >>> > >>> 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: > >>>>>>>>>>> > >>>>>>>>>>> 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 ) > >>>>>>>>>>> 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: > >>>>>>>>>>> > >>>>>>>>>>> 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 > >>>>>>>>>>> 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? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>> > >>>> > >>> > >> > > >
