Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

software release methodology



On Mon, 16 Jul 2007 08:49:25 -0400
Stephen Adler <adler-wRvlPVLobi1/31tCrMuHxg at public.gmane.org> wrote:

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

I've been involved with a lot of large projects, such as Digital's
(Compaq/HP) True64.=20
First, under CVS, the $Revision$" keyword can be used in a string.
So, if you coordinate all your code in the same revision tree, using
this will work. What we did in Tru64 was to compile the version strings
into the code so that it would show up using strings.=20

In a large project, there are subprojects with their own revisions.
Let's take the case of a compiler. The compiler has a number of
separate components, some of which might also be used in other tools,
such as the cpp(1) or lint(1) commands. In the case of a compiler, the
lexer, parser, optimizer, code generator may all be separately
maintained. Additionally, the revision a developer may want to see
might be the Subversion or CVS revision, but marketing may want another
revision string to use used with the --version option. Then we also
have the issue of libraries. Library versioning is another big issue.

Additionally, coupling a version number to a specific source control
system, such as Subversion, is also problematic. Maybe management
decides to change from Subversion to ClearCase.=20


--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org