Release Management

[Tkil]

>>>>> "Todd" == Todd Caine <todd_caine at eli.net> writes:

Todd> Ok, I'll be a bit more specific.  I am trying to figure out
Todd> best practices for managing software in a team environment.

there are probably many many books and web pages on this topic.  what
have you happened across so far?

Todd> Currently we are using CVS for revision control.  There is
Todd> no defined way to release software, besides cutting a formal
Todd> release via CVS and tar'ing it up.  

most larger environments i've been in have used a few other components
as well:

* a bug-tracking system.  i've used bugzilla and ddts.  there's also
  gnats.

* a program to extract a coherent set of version numbers, based on
  which bug numbers have been fixed in those versions.  it has to be
  able to check for "sandwiched" bugs, too.

  the only system like this that i ever worked with was a home-brew
  perl4 monstrosity.

in this environment, every check-in must have a bug number in the
comments.  you can then go through the comments and figure out which
versions fix which bugs.

(or, you can do it "mozilla-style": the head version is always the one
that is taken for every build -- but the tree is built continuously,
and any breakage is taken seriously.  large modifications are done on
branches, then merged ("landed") all at once.)

Todd> I just finished a project and have created a release in CVS.  I
Todd> then exported the software to a directory in /tmp where I built
Todd> a Solaris package.  Should the package stream be checked into
Todd> the repository as well?  Should it be under the same CVS module?
Todd> Even after I cut a formal release (branch and base tags)?

i'd just keep the package (with a release number and/or date either on
the filename, or in the file -- the package system probably has
this).  keep it in an archive somewhere, and back it up carefully.
(of course, that's true for the active code repository as well.)

Todd> Does anyone have any suggestions for selecting version numbers?

do you mean release numbers?  the most common scheme i've seen is
probably major.minor.patchlevel; patchlevels fix bugs, minors add
features, majors are rewrites (and usually imply a non-forward-
compatible change in functionality).

if you're asking "which versions of the individual files do we grab
for a given build", then the answer is the script i mentioned above,
or something similar.  you can do this by hand, if the team is small
and disciplined enough.  each person tags the components that they're
responsible for, and then you yank out every file with that tag.

Todd> Are README and CHANGES files sufficient for proper
Todd> documentation?

documentation for whom?  users?  administrators/installers?  future
maintainers?  each of these groups has different documentation
requirements.

remember that the documentation needs to be under source control, too,
and checked in with the same controls as the code base is.

Todd> I guess I'm just not aware of how release management is done in
Todd> other shops.  Any feedback would be greatly appreciated.

hopefully this has given you some ideas.  i'd like to see more
feedback, too, although a perl-specific list is probably too limiting
for this; look into joining some of the source-control or
configuration-management discussions (should be linkend off various
web sites.)

t.
TIMTOWTDI