incubator-droids-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chapuis Bertil <>
Subject Re: Moving some minor issues from 0.0.2 to 0.0.1 to get them committed before the release?
Date Mon, 07 Mar 2011 21:01:06 GMT
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 <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message