INN version numbering and display

Russ Allbery rra at stanford.edu
Mon Apr 3 07:04:28 UTC 2000


Russ Allbery <rra at Stanford.EDU> writes:

> INN's version would be identified as:

>         INN 2.3.0
>         INN 2.3.0 (20000401 prerelease)
>         INN 2.3.0 (20000401 CVS build)

This is now done, except that I used CVS prerelease instead of CVS build.

> The date for the snapshots would be inserted into the header by the
> script that builds the snapshots,

Not done yet, but will be shortly.  One night's snapshots will probably
identify themselves as CVS prereleases and use the date one runs make
until I get that script fixed (since I won't get to it before I go to
sleep tonight).

> and the date for the CVS build would be the date the source was compiled
> (no easy way to make it the date that the source was pulled from CVS,

Done.

> Programmatically, the INNVersion() interface would be deprecated
> (particularly since functions that use static buffers should be avoided
> whenever possible, and in this case all the information would be known
> at compile time), and at compile time, the values of two variables would
> be computed and compiled into libinn:

>     const int inn_version[3] = { 2, 3, 0 };
>     const char inn_version_extra[] = "20000401 prerelease";
>     const char inn_version_string[] = "INN 2.3.0 (20000401 prerelease)";

Done.

> We could then do away with the current #defines (which are very generic
> names and thus likely to eventually collide with something or other) and
> the pieces of INN that need to know the current version number can just
> pull it out of libinn.

Done.

The tar file renaming is still to be done.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the inn-workers mailing list