incubator-droids-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Frovarp <rfrov...@apache.org>
Subject Re: Moving some minor issues from 0.0.2 to 0.0.1 to get them committed before the release?
Date Sat, 05 Mar 2011 04:16:55 GMT
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.

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