BRM wrote:
> While I agree with Todd's comments, a few other thoughts...
>
> I would probably use a slight variation from what Todd suggested:
>
> 1. Stable trunk
> 2. Developers work in their own branch for working
> 3. Testers work in their own branch which becomes a specific release.
>
> So: Trunk is stable, developers branch from trunk to do their work, and
> then merge the changes back in. This can be as micro or macro as you
> like; but I would suggest that it be as micro as possible.
And I'd do the opposite with all new development work possible except
for disruptive changes done directly in the trunk so the developers can
take advantage of each other's work instead of finding big
incompatibilities when you try to merge their isolated changes.
With this model you would branch for each release, copying to tags for
each QA build and releasing the tagged build that passes QA. If you do
support updates of separate releases (instead of moving on the the next
release), you would do that work on the branch that produced the
corresponding tagged release repeating the tag/QA test process. Any way
you do it, you will have some unavoidable work to fix a bug that spans
supported revisions since you'll have to merge it to each branch that
needs it.
You have a fairly unstable trunk this way, but it doesn't matter because
you don't release from there and would probably try to coordinate
developer activity to stabilize code at the time each release branch is
created. This would not preclude separate development branches for
major changes but those need some planning for future integration unless
they completely replace the old versions.
--
Les Mikesell
lesmikesell_at_gmail.com
--
Les Mikesell
lesmikesell_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-30 18:07:48 CEST