Re: Branches, Tags, Code Workflow Question

Jim Reynolds wrote:
> I am trying to locate some type of SOP for software releases.
>
> If I have some software in the trunk, and I want to do a release
> build, should I tag what we have, or should I branch what I have?
>
> I figure I need to have the build somewhere, so that as bugs come in,
> I can have one person work in that branch or tag, then have other
> developers work on the main or trunk branch for the next release.
>
> So I am trying to find some type of document, or reinforcement that I
> can follow so I do things in a standard fashion.

If you want to label a version, with no intention of making changes to the
files within it, tag it. This is typically done when you release some code
to the outside world, so that you can later look at the exact code
released, to see why it is behaving in a particular way.

If you want to mark a version, with the intention of (perhaps) changing it
later, branch it. This is typically done when you want to apply a bug fix
to the currently released version, but the trunk has changes in it you do
not want to release yet.

A typical case is to tag something on release, then, if a bug is found
which has to be fixed in the release, branch from the tag and work on the
branch.

This is for a typical "software house" scenario, where compiled code is
released to other people for use on their machines, and where there may be
more than one version "in the field".

-- 
Nikki Locke, Trumphurst Ltd.      PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org