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 <[email protected]> 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
