[mdlug] Seeking best practice documentation for "dual-track" development

[Robert Meier]

Lugs,

Summary:
I'm looking for some internet or book documentation for
a best current practice in software development.
The usage of the documentation is primarily for citation in
management presentations.

The particular aspect sought is what used to be called 'dual-track
development (by AT&T, RCA, ...) and I suspect might now be called
'continuous development'.

What is the current buzzword?
  dual-track development? continuous development? ???
Where can I find a best practices description?


Detail:
The salient feature is TWO development trunks to separate
development scheduling from testing and sales scheduling.

The benefits include
  o sales always has a testing-approved copy to sell
  o sales always knows what features are deliverable today
       (those tested in the approval process)
  o sales always knows what features are soon to be deliverable
       (those in testing but not yet approved)
  o testing can be thorough, rather than compromised for sales date.
  o testing is more predictable so can be more easily automated
  o development can design projects to minimize overall cost and
    maximize efficiency rather than fit a sales date, or compromise
    quality when sales dates change.


                 --featu 2--+
                /          / \
developers  --feat1--+    / --feat3--+
           /  /     / \  / /   \    / \
        ===============+========+======+== all bugs get fixed
            \         \       \
testing      \         \   bugs\
              \         \ / /   \
               ======+   ====|   =======+ only "safe" bugs get fixed
               approve\   reject  approve\
                       \                  \
                        ================== ===============
sales   [advertise]     [burn and ship]    [burn and ship]

Though not required, references that use cvs would be
especially useful.

What is the best way for testing to snapshot what is being tested?
  separate repository? special tag?
What is the best way for testing to mark what is approved?
  archived package? separate repository? special tag?
What is the best way for development to mark
  what is needed for integration but not yet ready for testing?
    special tag? absence of special tag?
  what is a "safe" fix suitable for the next testing cycle?
    special tag? absence of special tag?

TIA,
-- 
Bob

  "The surest sign that intelligent life exists elsewhere in the 
   universe is that none of it has tried to contact *us*."
     -- Calvin and Hobbs