On 3/3/2011 1:53 AM, Chapuis Bertil wrote:
> You are probably right. I see the stable branch more as a snapshot of
> the trunk, and the merges should mainly be done from trunk to stable,
> however I don't know how time consuming it is to perform these merges.
> The point is that the release should not be blocking. Do you think we
> can find another alternative?
Yes, the merges would go from trunk to stable. But if they are being
done all of the time, there isn't much gain, it's just an extra step. If
they aren't being done all of the time, it becomes a lot more work.
The amount of time that a release would really be blocking should be
quite minimal, and for a low volume project it shouldn't be that big of
a deal. The biggest blocking issue here is that we're trying to figure
out how to do a release, and are waiting for that before calling a vote.
In fact, all we would really vote on is the code denoted by a revision
number in SVN. Identify that revision number, tag it as an RC, and let
the trunk continue on development. If necessary you branch the RC to
create new RCs and merge any bug fixes into trunk. A project like this
probably isn't going to go through many RCs for a release.
I am personally of the belief that I would much rather rarely bring
patches forward from an RC to trunk than the more frequent path of trunk
to stable. I'm not opposed to the idea of stable, I just think it's more
work. However, if there are going to be frequent releases, or long
release processes, stable might prove to be very helpful.
|