[Chandler-dev] How we develop post Preview : SVN topology

[Reid Ellis]

A big +1 for s1.b

Reid

On Sep 5, 2007, at 16:31, Philippe Bossut wrote:
> Possible strategies:
> 1. 2 main branches: one for "open" dev work going toward the next  
> major release and one for "restricted" commits to fix the official  
> release
> s1.a: Evergreen trunk: use the trunk for 0.7.x (restricted commit)  
> and open a dev branch. When the dev branch is stable, merge it to  
> the trunk (or call it the trunk) and repeat.
> s1.b: Open dev trunk: use the trunk for open dev toward the next  
> major release, open a branch for 0.7.x work. Note: wxWidgets for  
> instance is using such a strategy.
> s2. Multiple dev branches: maintain the trunk evergreen, devs  
> develop on their own branch and merge onto the trunk once their  
> feature/change pass tests and scrutiny by the community. Note: used  
> on really big FLOSS projects (Linux) and by commercial projects  
> (considered as best practice under Perforce for instance).