software release methodology

[david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org (David Kramer)]

Stephen Adler wrote:
> Guys,
> 
> For those of you who are actively involved in software projects, I was 
> wondering how you go about giving your software project a version 
> number. Specifically, how do you tag the version string in your code so 
> that when you do something like
> 
>   myexecutable --version
> 
> then prints out the version number of the software. Are there methods 
> within code repository tools like subversion or cvs which will fill in a 
> string or something with a version number or tag string so that when you 
> do a checkout, it automatically replaces the string? Or do you have to 
> manually change a string constant within your code and then commit the 
> change to the released version of the code?

I want to expand on a couple of the other areas.

Matthew Gillen talked about Subversion, and I take issue with some of 
what he said.  First of all, Subversion (my favorite for some years 
now).  has facilities to tweak files before they get checked in, and 
even do things like warn the user if certain conditions are not met, 
etc.  They're called "hook scripts", and that one is called the 
"pre-commit hook script".  In the script's environment are environment 
variables in automatically defined for version, repository URL, etc.

There's a problem with doing things this way, but it's not really a 
Subversion-specific proble.  It has more to do with using *any* kind of 
method that's not specifically for that purpose in *any* revision 
control system.  That is, the substitution happens before the checkin, 
so the revision number embedded in your code will be the the version 
with your last *fucntional* changes, not the new version with the 
embedded version.

However, Subversion does offer a very good way to do this that gets 
around this problem nicely.  See
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html


Nathan Meyers was hinting at an important distinction between revisions 
and versions.  I think he was, anyway.  Revisions denote a new 
checked-in version of the software.  But (if you're doing things right) 
that can happen dozens of times between points where you have a usable, 
testable, piece of software.  For this reason, it's often much less 
useful a number than the version (or release), which denotes a snapshot 
of the software you actually care about.  So maybe this revision thing 
is overrated.  All version control systems I know of have a mechanism 
for tagging files with a keyword, or specifically naming a release, so 
it's usually pretty easy to manage your software at that level.  In fact 
you *can* use a pre-commit hook in Subversion to shove in a version 
number, because the act of checking in files does not inherently change 
it.  No Heisenberg issues ;)


Greg Rundlett correctly points out that you usually need to handle the 
outputting of the version number somehow in your code, by putting in a 
special version printing function in it.  However, there's another way. 
  If you put a delimiter before and after the keyword, you can use a 
grep-like tool to find the version number easily.  I happen to like this 
way of doing things, because (1) Less code means less bugs, (2) it will 
work with almost any file, not just runnable files that take arguments 
and output text.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.