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

[Philippe Bossut]

Hi Grant,

I like your "s3" solution (which is similar to what I considered as 
being s1.b with mitigation). It's also the best solution so that we can 
achieve things like "frequent updates with significant features" 
mentioned by Andi in his email on another thread.

Couple of consequences on "dev's daily life" with that solution:
- the "trunk" (0.7.x) should be in a shippable state anytime
- the "trunk" (0.7.x) is evergreen meaning that bogus commits will be 
rolled back promptly
- the "trunk" (0.7.x) is open (i.e. no required code review pre commit) 
for small bug fixes or incremental work *but* all commits must be post 
commit reviewed by the community
- dev branches will be merged to the trunk after having been code 
reviewed by devs and tested by QA. We'll need to communicate quite 
openly then on the creation, availability, testability, etc... of those 
branches so that the merging process can work.

I also like the "per feature" branches (i.e. several devs collaborating 
on a feature) rather than the per dev though, in lots of cases, those 2 
cases will be the same.

Last: I think that though most people say they don't have a strong 
opinion, we better have this right and agree on it as it has 
consequences on how we manage releases and how we work on a daily basis.

Cheers,
- Philippe

Grant Baillie wrote:
>
> There's an s3 here:
>
> - Stable trunk (i.e. 0.7.x work) + per-feature (and/or per-developer) 
> branches. This is essentially how twisted does things IIRC.
>
> Personally, I don't have a particularly strong opinion about this 
> choice. For example, no-one is singing the praises of s2, but I'd be 
> fine with it. (Using SVK, it's not a big deal to merge properly 
> between branches. My pattern is to make local branches often anyway).
>
> --Grant
>
> On 5 Sep, 2007, at 13: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).
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev