I am trying to reach a conclusion on whether to use date-stamps or
traditional version numbers first of all, so I will neglect the other
points of Guido's posting for the moment, if I may.
> In effect - version numbers are great with three parts, a major,
> a minor, and a (patch)level. A mapping can be given when two
> parts are derived from date numbers - proposing
> 6.2003.05 = <generation>.<year>.<month>
I agree that these three-level-version schemes make sense in some
projects. But looking at our effort here, I feel that ...
- we don't have any beta/alpha/patch-level releases and
- we don't have any distinction between minor and major releases, at
least none that I cat think of.
From a minimalistic point of view, we should call our releases
autoconf-archive I, II, III, IV, ... _That_ would be cool. Albeit hard
to read in few years. :-)
My reasons to prefer date-stamping are:
- Everybody can figure out, which one is the most up-to-date.
- A simple "ls -l" will show the files in chronological order.
- The "ChangeLog" is going to be straight-forward.
- It is a simple and unambiguous system.
Anyway, I am perfectly comfortable with a major.minor scheme, but in
order to be really _happy_ with it, I would like to see a definition
of what constitutes a "major release" and what does not.