software release methodology

[greg.rundlett-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org (Greg Rundlett)]

On 7/16/07, Stephen Adler <adler-wRvlPVLobi1/31tCrMuHxg at public.gmane.org> 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

The way you get a program to output version information is to program
that function into the program ;-)  I'm not trying to create a
circular defintion, but seriously explaining that you must program an
option (by convention that option is '--version', the short option
might be -V since -v mostly means 'verbose' --again this option naming
is just done by convention) which when given to the executable will
output some information.  You can add this type of functionality to
your program using the 'getopt' program from the GNU project (see 'man
getopt') For PHP projects, there is a nice Console::Getopt package
available from PEAR that does the same thing
http://pear.php.net/package/Console_Getopt.

When you talk of source code control system versions, you are talking
about something entirely different.  Rarely if ever do the two mix.
The program version number might include a reference to the source
code control system's internal representation of the revision number,
but it's very rare.  For example, the source code control revision
number might be r7413 for a project that is at version 0.9.2.  Mix
them together?  0.9.2-r7413
>
> 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?

In addition to programming your program to output the correct
information in response to command options (or webpages that contain
version information) many projects also follow a convention of using
either a configuration file with a version variable,

grep -i version ./serendipity_config.inc.php
// The version string
$serendipity['version']         = '1.1.3';

or maybe even a version number in a file.  E.g.
cat /etc/debian_version
4.0

Once the version information is recorded somewhere accessible to the
application, the application can be programmed to read, show and react
to that version identifier.

<sarcasm level=10% truth=90%>
Obviously whatever version scheme that makes perfect sense to the
developers will someday be thwarted by a marketing department that
thinks their notion of version is better.
</sarcasm>
So, putting it into a configurable location independent of the VCS is
a must really.

> Cheers. Steve.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>


-- 
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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