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