Thanks for the clarification. As you mentioned, in our case we will probably
have very few RCs and simple merge scenarios. Until we release, the stable
branch is probably a reasonable option. I can handle the task of merging the
changes thereafter.
On 5 March 2011 05:16, Richard Frovarp <rfrovarp@apache.org> wrote:
> 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.
--
Bertil Chapuis
Agimem Sàrl
http://www.agimem.com
|