From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-08-27 02:42:53
Michael Fawcett wrote:
> On 8/24/07, Johan Nilsson <r.johan.nilsson_at_[hidden]> wrote:
>> Beman Dawes wrote:
>>> Anyone else care to hazard an opinion on
>>> "branches/release_candidate" vs "branches/release"?
>> +1 for "branches/release"
> I would vote for "candidate" instead of "release". "release" implies
> that it has been released, and "release_candidate" is too long. I
> thought about "RC" for a bit, but I think it's too short. And, at the
> risk of going full circle again, I really like "stable".
Ahh, didn't see "stable" in the discussion. I like that as well.
>> Shouldn't the "release_candidate"(s) be found under tags/.../RC_nnn?
>> Won't this be a possible source of confusion?
> Well, as I understand it, there is only ever 1 "release candidate",
> and that is branches/release (or whatever the name will be).
> Libraries will be developed on their own branch, and then merged into
As I understood it, there will be a single "relase candidate" _branch_, used
for the "ever-available stable build". The individual release candidates
would still need to be separately tagged for "official" release candidates.
Imagine that someone declares the "official" release candidate for Boost
1.x.y being available under "branches/release". Now, a number of users
download that candidate, testing it. The next day other users download from
the same location, testing it. During that period of time something happened
to the release candidate (e.g. one library was fixed). When the users report
and discuss possible problems and errors with the release candidate, how can
they easily know _which_ release candidate (i.e. the code state) that they
are talking about without also having the candidates tagged - e.g. how can
someone be able to answer the following questions: Did you notice the
problem in RC_x_y_1 already? Is it fixed in RC_x_y_2?
If I'm completely wrong, I'd be grateful for someone correcting me.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk