Basic resource lifecycle: a new proposal for handling "mutable versions"

After thinking again on what I wrote on lifecyles I find that perhaps my idea
wasn't so bad. I'm not sure I want a different resource type with VARIANT-CONTROL.

Why not define a version resource as having a state:

VersionResource = VersionControlledResource VersionName State
State           = "working" | "approved" # The names aren't that important.
The lifecyle has two states: "working" -> "approved"

I really wouldn't like to make a division between document and code versioning.
Because code (Speaking  of a software release) also brings related documents.
Requirements, Design specifications, User manuals ... These documents often are
managed like Lisa describes it. This means they are mutable being
in a "working" state, go to a "to-be-reviewed" state and finally are in state
"approved". Just to give a simple example like you probably will find it in
a bigger software project.
So by introducing a state property we wouldn't introduce something that's out
of the world. You will find lifecycles for documents in every decent Software
Configuration Management Plan.
Now for code we just do a CHECKIN and set state to "approved" (Skipping "working")
For documents we can set state to "working". As long as the author thinks he
could still change something he can leave it in this state. And anybody is
warned by the state that it can still change.
Would that be OK for you Lisa ?
OTOH there will be a time when the document version is declared finished. Then just
promote it to "approved". Being "approved" also will be required for a version
to be usable as a base for delta storage of a successor version or inclusion in
a baseline.

Cheers, Edgar


-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Native Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein

Received on Saturday, 6 January 2001 17:18:58 UTC