RFC: Keeping Track Of Software Versions.
-
Hello All.
(Sorry for the cross post if some of you are listening to both!)
I have been trying to figure out a good scheme for keeping track of
software versions and build numbers, etc.
Part of my consideration is a way to use CVS to keep track of this, or
some other way of automating.
We are finding it increasingly necessary to keep track of this in a well
thought out way so we can better handle releases, internal
builds/versions, etc. but I have not really come up with a good scheme
for this.
I know how to create tags and branches in CVS. My concern is more along
the lines of managing the whole process of making internal builds, beta
builds, public builds, etc.
One idea which we had was to setup a machine here to be a build server,
and nightly (or every couple of nights, every week, whatever makes
sense!) it would checkout the source for our various products, increment
a build number in a file, build the product, commit the build number
file, then move the build to a repository which internal staff could
grab it from and starting testing it.
Then I would like to tie this to our bug tracking software to keep
track of what is assigned to a particular build (or at this level
version) and what has been fixed/added in a particular build, which
among other things would help us automate our release notes.
Could anyone share their experiences on this with those of us struggling
to figure it out. Or point me to some documentation or a good book on
this sort of thing?
Thanks in advance,
Michael. -
You can use 'make' to do this (or, I'm sure jam as well). Together with
CVS tags, you've got enough ammo to e.g. 'make tag BUILD=vx.y' to tag a
new release or something of the like.
The challenge is to create a bunch of make targets and manage them. But
it's not too hard to come up with a set of sensible targets and thier
commands.
(One of these days I'll learn the new build system....)
Steve
On Mon, 3 Dec 2001, Michael (Lists) Clark wrote:> Hello All.
> (Sorry for the cross post if some of you are listening to both!)
>
> I have been trying to figure out a good scheme for keeping track of
> software versions and build numbers, etc.
> Part of my consideration is a way to use CVS to keep track of this, or
> some other way of automating.
>
> We are finding it increasingly necessary to keep track of this in a well
> thought out way so we can better handle releases, internal
> builds/versions, etc. but I have not really come up with a good scheme
> for this.
>
> I know how to create tags and branches in CVS. My concern is more along
> the lines of managing the whole process of making internal builds, beta
> builds, public builds, etc.
>
> One idea which we had was to setup a machine here to be a build server,
> and nightly (or every couple of nights, every week, whatever makes
> sense!) it would checkout the source for our various products, increment
> a build number in a file, build the product, commit the build number
> file, then move the build to a repository which internal staff could
> grab it from and starting testing it.
> Then I would like to tie this to our bug tracking software to keep
> track of what is assigned to a particular build (or at this level
> version) and what has been fixed/added in a particular build, which
> among other things would help us automate our release notes.
>
> Could anyone share their experiences on this with those of us struggling
> to figure it out. Or point me to some documentation or a good book on
> this sort of thing?
>
> Thanks in advance,
> Michael.
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> -
On Monday, December 3, 2001, at 12:01 , Michael (Lists) Clark wrote:> Could anyone share their experiences on this with those of us struggling
> to figure it out. Or point me to some documentation or a good book on
> this sort of thing?
>
I haven't played with it yet, but you may want to check out CruiseControl
http://cruisecontrol.sourceforge.net/
"CruiseControl is a tool for setting up a continuous build process. It
builds upon the Ant project from Apache
( http://jakarta.apache.org/ant/index.html) by providing a set of tasks to
automate the checkout/build/test cycle, and provides a servlet for viewing
the status of the current build as well as the results of previous builds.
"
This is the tools they use at ThoughtWorks for J2EE stuff but if you set
up an Ant project for building your WO5 app this might be a route to go.
--
Ian P. Cardenas
Computer Scientist, Software
http://www.ultraviolent.com/resume/covers/osx.html
