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 <rfrov...@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
