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
