incubator-droids-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chapuis Bertil <bchap...@agimem.com>
Subject Re: Moving some minor issues from 0.0.2 to 0.0.1 to get them committed before the release?
Date Thu, 03 Mar 2011 07:53:04 GMT
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?

On 3 March 2011 00:33, Richard Frovarp <rfrovarp@apache.org> wrote:

> On 03/02/2011 04:03 PM, Chapuis Bertil wrote:
>
>> Good point. Personally I think that the release should not block the
>> development of 0.0.2. It seems that the solution proposed in [1] could
>> make
>> sense in our case. if there is no objection I propose to create a stable
>> branch with the current state of the trunk and to start applying the
>> patches
>> for 0.0.2 on the trunk. The 0.0.1 release will be made from the stable
>> branch.
>>
>> [1] -
>> http://lsimons.wordpress.com/2010/02/19/using-long-lived-stable-branches/
>>
>>
>>
> The Incubator docs link to that blog entry as well. I don't know that I see
> the benefit of going to this.
>
> The entry states this:
>
> "Usually when explaining this model to a new group of developers they
> realize at some point someone (like Bob) or some people will have to do the
> work of merging changes from trunk to stable, and that the tool support for
> stuff like that is a bit limited."
>
> and this
>
> "For small and/or mature projects I do often revert back to having just a
> trunk."
>
>
> So who is going to do that work on this project? My concern is that merges
> will always happen, which is just an extra step to do beyond using just a
> trunk. The other option is that merges rarely happen, and trying to figure
> out what needs to be merged becomes a problem.
>



-- 
Bertil Chapuis
Agimem Sàrl
http://www.agimem.com

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