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