todd_caine at eli.net
Wed Sep 19 12:59:09 CDT 2001
Just in case anyone else is interested......
The Terminator Rat wrote:
I've read a few books and done release management for a few
I wouldn't say I'm an expert. Like my friend Kelly Russell once
"I'm not an actor, but I play one on T.V.".
You should *not* check in the Solaris package, since it is
merely a way of
repackaging the repository's sources. However, you probably
want to make
a "release" target in your Makefile or a "mk_release" script
the package for you. This will ensure that you can recreate the
with the same arguments and files at a later date. Be sure to
sources by name (don't just use '*.pl', for instance) so that
list in the package will be consistent.
You should use branches to manage bug-fixes and other mods on
software. Don't forget to baseline each branch, or you'll have
pulling up the fixes to the mainline.
When building your package, you want to create a virgin source
populate it with CVS export. For instance:
rm -rf build
cvs export -d build -r release_1_2_3 project
Of course, all of the above could be built into the 'release:'
the Makefile or your mk_release script.
Version numbering is more art than science (and pop art at
first official public release is usually 1.0, but that can
defacto standard for version numbering is :
The patchlevel is typically bumped when a bug fix is made. The
number is usually bumped when significant new functionality is
change in the major number usually indicates extreme changes
previous version (i.e. a re-write or re-design).
Don't forget that CVS doesn't allow you to use '.' in symbolic
tags -- substitute them with '_' characters. For example,
When I was doing release management on the PIX, we bumped the
from 3.4 to 4.0 because Checkpoint had bumped Firewall1's major
The differences between the two "major" versions was minimal,
marketing department thought it was something of a coup. Not
suggesting doing this, but it's a good illustration that version
isn't entirely a technical issue.
Keeping README and CHANGES files is often sufficient for
changes made to the release. You can generate the CHANGES file
fact if necessary. An easy way to do this is to browse through
history since the last release.
Alternatively, create a diff against the previous release and
changes made. Obviously this is much more time-intensive, but
catch things that didn't make it into the commit history (and
To go back on my word above, you may wish to keep a directory
the repository that contains the packaged software for each
instance, create a 'dists' module and check in each new
Be sure to turn off keyword expansion ('cvs add -kb') on the
prevent them being corrupted by RCS keyword expansion. Check
them in with
the name they were distributed by (i.e. 'foo-1.2.3.tar.gz').
This is much
more useful in the long run than patching the previous binary.
Another very cool and handy thing you can do is add build
the binary so you can identify the exact rev and build of the
a later date. A common way to do this is to build a target into
Makefile that updates build information in the package.
<ELI> There's a good example of adding build information in the
sources -- in particular, look at how the Makefile runs
create vers.c. </ELI>
A similar thing would be very simple in Perl. The following is
handy in Perl for single-script programs:
use vars qw/ $VERSION /;
my $REVISION = '$Revision: 1.67 $';
($VERSION) = $REVISION =~ m/: (\S+)\ \$$/;
Then you can arrange for your script to print the version if
this case, you are making the script's version an identity with
revision number. The RCS $Name$, $Author$ and $Date$ strings
be used to build up a build/release information string.
Probably the two most useful things you can do are to create and
a CHANGES file, and automate the release process as much as
an ideal world, after getting the green-light from your testers,
just "make release" and hand the package to whoever does your
(i.e. your FTP site, mail it out on CD-ROM's, etc).
Hope that helps,
On Wed, 19 Sep 2001, Todd Caine wrote:
> I am trying to figure out best practices for managing
software in a team
> environment. Currently we are using CVS for revision
control. There is no
> defined way to release software, besides cutting a formal
release via CVS
> and tar'ing it up. I just finished a project and have
created a release in
> CVS. I then exported the software to a directory in /tmp
where I built a
> Solaris package. Should the package stream be checked into
> as well? Should it be under the same CVS module? Even after
I cut a formal
> release (branch and base tags)? Does anyone have any
> selecting version numbers? Are README and CHANGES files
> proper documentation? I guess I'm just not aware of how
> is done in other shops. Any feedback would be greatly
> Thanks in advance.
> = GEekList -- GeEk oF thE WorLd UniTed -- Techie
O----O Karl F. Schilke - rat at cynical dot org -
==\/== "If I was just half the man he is ... I'd probably
More information about the Pdx-pm-list