Build Number revisited

[Dustin Sallings]

On Nov 27, 2007, at 21:00, Barry Roberts wrote:

> I'm just curious.  My home-grown CI system automatically fetches this
> number, puts it into the build, and uses it to uniquely identify that
> build.  Is that not a build number simply because it's generated by  
> CVS
> or hg as opposed to the update/build/deploy scripts?  Or is it because
> not every number corresponds to a build?

	The latter.  It's not a build number because it doesn't represent a  
build.  It only identifies a coordinated change from the point of view  
of one machine.

	In another process on another machine, you update a tree to its view  
of that number (which is hopefully the same, although a fresh clone  
from that central location should be enough to guarantee the sequence  
always lines up), and you do a build.

	Mercurial has a globally unique identifier which simplifies the  
process in your CI system and for your developers, but it doesn't suit  
your needs.

> My testers don't use cvs or hg, so the build number has to available
> from within the built and deployed application (they're mostly web
> apps).


	Sure, and that makes perfect sense.  It sounds like you want two  
different things:

	1)  Something to identify all of the changes that went into a  
particular build.
	2)  Something to offer QA as a means to say, ``contains previous  
stuff and new stuff.''

	At my previous company, we used perforce and buildbot.  perforce kind  
of did #1 as well as it could by syncing to a particular changelist  
before a build, and buildbot did #2 by creating a sequence of numbers  
that grow independently.

	For some of my personal projects, I can accomplish pretty good  
results without any sort of central authority.  For example, if you  
were to use my digg java API, you could find out everything you need  
to know to reproduce the tree that built it by doing this:

% java -jar digg-1.2.jar
spy.jar  on Sun Nov 04 16:15:00 PST 2007
Build platform:  java 1.5.0_13 from Apple Inc. on Mac OS X version 10.5
Tree version:  ab0408920c56 tip
(add -c to see the recent changelog)

	But I include a full changelog within the jar as well so someone who  
doesn't want to bother to find my repo can still find out what went  
into a build quite easily:

% java -jar digg-1.2.jar -c | head -20spy.jar  on Sun Nov 04 16:15:00  
PST 2007
Build platform:  java 1.5.0_13 from Apple Inc. on Mac OS X version 10.5
Tree version:  ab0408920c56 tip
  -- Changelog:

changeset:   45:ab0408920c56
tag:         tip
user:        Dustin Sallings <dustin at spy.net>
date:        Sun Nov 04 16:14:56 2007 -0800
summary:     Added tag 1.2 for changeset ad66c21a76cf

changeset:   44:ad66c21a76cf
tag:         1.2
user:        Dustin Sallings <dustin at spy.net>
date:        Sun Nov 04 16:14:53 2007 -0800
summary:     Making PagingParameters public again (for the constants).

	

-- 
Dustin Sallings