Version numbering RFC

[Eric S. Raymond]

I have tried to standardize the way we dump the NTPsec version in a way
that is useful, short, and won't break if we ever have to do
repository surgery on the history.  (The last criterion excludes using
the git SHA1 ID.)

So:

esr at snark:~/software/ntp-rescue/ntpsec$ build/main/ntpd/ntpd -V
ntpsec-0.9.6-499 2016-12-26T16:12:20Z

This is <name>-<version>-<tick> <date>, where <tick> is the commit
count since the last tag.

For a shorter version (used in ntpmon, where it's confusing to have
two timestamps in the status bar) I just use <name>-<version>-<tick>.

There is, however, one problem with the way we've been doing things
that I'd like us to fix before 1.0.

A newbie looking at ntpsec-0.9.6-499 would quite reasonably assume it
means tick 499 after 0.9.6.  It doesn't, because we bump VERSION just
before release rather than just after.

My proposal is that we change this before more water has gone under
the dam.  That is:

1. VERSION should correspond to the last tag, not tne next one.

2. It should *not* be bumped when we ship 0.9.6 - that will bring it
   into sync with the new convention.

3. After 0.9.6, I will add logic to bump the contents of VERSION after
   shipping to devel/release, with --major, --minor, and --point
   options.

Additionally, we should plan for 0.9.6 to be a short-cycle release so
the number of duplicated short release IDs is small. Not that I think
that's a real problem, as the date stamp normally disambiguates and
we don't yet have any history of actually needing them to be unique.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[The disarming of citizens] has a double effect, it palsies the hand
and brutalizes the mind: a habitual disuse of physical forces totally
destroys the moral [force]; and men lose at once the power of
protecting themselves, and of discerning the cause of their
oppression.
        -- Joel Barlow, "Advice to the Privileged Orders", 1792-93