RE: Release management policy fundamentals

Try this http://www.cmcrossroads.com/bradapp/acme/branching/

It's quite involved, but explains several approaches that can be taken
to handling project branching and answers possible solutions to your
questions.

Jay

----
Please don't tell me my company's disclaimer is mega long, I know but
it's not something you can change in a multi-national company. I
apologise.
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Nick Patavalis
Sent: 12 January 2005 03:44
To: users@subversion.tigris.org
Subject: Release management policy fundamentals
The subversion book, the online manuals, as well as this mailing list,
are excellent resources for learning how subversion works, and how you
can command it to do what you want. What I have been unable to find,
though, in printed or online material, are advices, discussions, or
guidelines, about the fundamentals of revision management *policies*
(as opposed to mere mechanics). Though policies naturally differ
depending on the needs of a project, I do believe that for a spectrum
of tasks (e.g. software release management) it would not be impossible
to derive and classify a few sets of fundamental models, or so to say,
"operational canons" upon which one could base the variations that
suit the needs of a specific project.
Lacking a formal discourse on such subjects, the next best thing would
be a description of the specific policies applied in real-world
projects, and possibly the rationale behind them.
I was trying to derive such an example by examining the structure of
the "http://svn.collab.net/repos/svn/" repository. Sadly, though, by
the structure of the repo alone it isn't easy to derive the rules that
lead to it, and the rationale behind them.
So I was wondering; is there any document describing the overall
structure and the release management policies of the project? Is
there, for example, a document that answers to questions like:
When are branches line 1.0.x created (before the first release in the
1.0.x line, afterward, or maybe before the next major release)? Where
developers usually work (on the major-release branches or the trunk)?
What happens during release-stabilization periods? etc...
Any pointer to such information, or a short description of the
respective policies, either for subversion, or for any other
relatively complex project would be greatly appreciated.
Regards
/npat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org