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