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).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
