INN version numbering and display

Russ Allbery rra at
Sun Apr 2 07:51:55 UTC 2000

I've been thinking about the various ways in which we use version numbers
and how they're displayed and think I'd like to propose a few chages and
see if there are any objections.

Currently, INN displays its version like:

    INN 2.2.2 13-Jan-1999

or in general:


where PATCHLEVEL actually contains the second and third digits of the
version and there are also RELEASE_C, PATCHLEVEL_C, and SUB_PATCHLEVEL_C
#defines that are supposed to contain the pure number versions.

I don't find the release date particularly helpful if one has an accurate
version number.  I'd also like to start marking both the snapshots and the
CVS code with some sort of version identifier so that people can tell more
easily what they have, and ${LOCAL_STRING} looks to me like the right
place to do that.

Since we're only generating one snapshot per day, and seem likely to for
the forseeable future, I'd also like to change the snapshot naming
convention to just be the standard ISO date.  So the snapshot tarballs
would look like:


instead of the current:


which are longer, harder to read, and harder to cite.  (If you're bleeding
edge enough to be using snapshots, you should know what version is stable
without having to have it in the file name.)  INN's version would be
identified as:

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

for releases, the nightly snapshots, and a build directly from the CVS
tree, respectively.  The date for the snapshots would be inserted into the
header by the script that builds the snapshots, 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, but those of us using CVS
directly can do our own identifiction of what vintage of source we have).

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)";

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.

Does this generally make sense?  Anything being lost by taking this
approach?  Any better approaches to suggest?  I volunteer to do all the
work.  :)

Russ Allbery (rra at             <>

More information about the inn-workers mailing list