Is this a convincing improvement in process: CVS to SVN (was Branching strategy - Feature vs Release)

I want to move my dev teams to subversion. Right now we use CVS, we're
in different countries and experimentation and research shows
Subversion having some very strong arguments in its favour. I'd also
like to improve our process and this is how I propose to manage it,
does it sound reasonable - I've tried to be brief.

NB: We're small teams, Dev and QA are often the same people wearing
different hats but they're still defined stages in development and
people are either wearing one hat or the other at a time. Product
management is a completely different beast - when marketing gets
involved 'beast' is the best description.

What we do now (in CVS)

Development: Work towards next release milestone (set of features) (HEAD)
- Develop features, usually on HEAD unless they expect to be complex
and interfere with other developers.
- Reach a release milestone (set of features), tag as BETA (passes to QA)

QA: Test and correct BETA (BETA branch from BETA tag)
- Fix bugs
- backport selected enhancements that might reduce bug
exposure/severity if bug isn't to be fixed in this release.
- Once stable, tagged for RELEASE (dated and versioned) (passes to
product management)

QA: If RELEASE requires fixes (FIX branch from RELEASE tag)
- Fix bugs
- backport selected enhancements that might reduce bug
exposure/severity if bug isn't to be fixed in this release.
- Once stable, tagged for RELEASE (dated and versioned) (passes to
product management)

Merges forward from BETA and FIX branch into HEAD are common and
usually performed by one person (these have been a little fragile if
HEAD severely diverges from BETA or FIX)

Note that rarely are features developed in a branch, meaning that
reaching a milestone requires un-utilised people to finish up and
transition to QA as the BETA milstone approaches.

Given the ease of creating tags and branches in Subversion I'd like to move to

[Using this single project example of a repository structure]
/
  dev/
    project1/
      trunk/
      tags/
        milestones/
        releases/
        other/
        products/
      branches/
        bugs/
        features/
        fixes/

Development: Work towards a dev release (trunk)
- Develop features in branches/features/FEATURE, merge to trunk once
stable. This is done by the developer responsible for the feature.
Announce to dev management who will collate into reports for product
management.
- fix bugs in branches/bugs/BUG, merge to trunk once stable. This is
done by the developer responsible for the bugfix.
- When product management decide trunk has reached a milestone, tag as
tags/milestones/MILESTONE (passes to QA)

QA: Test and correct milestone (branches/fixes/MILESTONE from
tags/milestones/MILESTONE)
- fix bugs in branches/bugs/BUG, merge to branches/fixes/MILESTONE once stable.
- backport selected enhancements that might reduce bug
exposure/severity if bug isn't to be fixed in this release.
- Once stable, tag as tags/releases/RELEASE (development release name)
(pass to product management)

QA: Fix a wild release tags/releases/RELEASE (branches/fixes/RELEASE
from tags/releases/RELEASE)
- fix bugs in branches/bugs/BUG, merge to branches/fixes/RELEASE once stable.
- backport selected enhancements that might reduce bug
exposure/severity if bug isn't to be fixed in this release.
- Once stable, tag as tags/releases/RELEASE (numbered development
release name) (pass to product management)

Prod Management: If a dev release has reached a commercial milestone
and degree of stability
- tag with tags/products/PRODUCT (external numbering, possibly with date)

Expect to merge forward from fixes branches to trunk if the issue
affects next release.

This uses branches much more rigourously and ensures that, at any
time, trunk is releasable to QA as a set of features.

Note I've also tried to decouple product versioning from development
releases so that product management could simply choose not to let a
given development release go into the wild and wait for the next dev
release. If development announce feature completions to product
management then product management can opt to mark a milestone at any
time and start a beta program. If the beta program takes too long and
a more commercially important feature arrives, product management can
take this version into beta instead - these steps don't produce
customer facing version advancements and don't interfere with
development process.

Comments. Recommendations. Do people use this mechanism or something similar?

For my next trick I'll have to document this in steps that all parties
can follow (and produce issue resolution for those times when someone
drops the ball).

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org