Re: Finding out the highest revision number on the source tree.

[Greg A. Woods]

[ On Monday, July 30, 2001 at 10:49:53 (+0200), Waltham, Nicholas (GILW) wrote: 
]
> Subject: Finding out the highest revision number on the source tree.
>
>  I was just wondering, how is is possible to find the highest revision number
> across the source tree. I would like this to be the version number of the
> software (or is this a bad idea - I can think of a number of disadvantages) -
> perhaps I should just ask what is a good strategy for versioning?

That's just a BAD idea....  :-)

If I were you I'd just pick a good version numbering scheme and then
mangle those numbers into tags.

Here's my version numbering scheme.  Appologies to those who've seen it
before (hit 'd' now...  :-)

I mangle the number with 's/\./_/g' and I usually prepend either the
product short name with a separating '-', or the string "Release-", to
the tag too, that way when you see $Name expanded (with 'cvs export -kv')
in source text it looks more meaningful.

----------------------------------------
Release Numbers:

We essentially follow the essence of the Berkeley CSRG version numbering
scheme for identifying releases.  That is to say we increment the third
number (3.7, 3.7.1, 3.7.2, etc.)  whenever we generate a release of bug
fixes (what might traditionally be also known as a "patch" release), and
we increment the second number, or the minor release number, (3.7, 3.8)
whenever we add any new features or make other important user-visible
changes, and lastly we increment the first number, or the major release
number, (3.*, 4.1) whenever we make major or architectural changes.

We also throw in a smattering of GNU-isms too -- the alpha-test and
beta-test releases of upcoming proper releases should have a ".80" or
".90" (respectively) appended to the current release number (3.7.5.80
would be the first alpha for 3.7.6, continuing with 3.7.5.81, 3.7.5.82,
etc., 3.7.5.90 would be the first beta, continuing with 3.7.5.91,
3.7.5.92, etc. until finally 3.7.6 is released; for another example the
first alpha for 4.1.1 would be 4.1.0.80, continuing with 4.1.0.81,
4.1.0.82, etc., 4.1.0.90 would be the first beta, continuing with
4.1.0.91, 4.1.0.92, etc., until finally 4.1.1 is released).

One special case rule not yet described covers the releases preceding
the initial release, which would might start with semi-private releases
numbered "0.x", eg. 0.1.80, 0.1.90, 0.1.91, 0.2, 0.2.80, 0.2.90, 0.3,
etc., then full public releases numbered "1.0.x", eg. 1.0.80, 1.0.90,
etc. until 1.1, the first fully official release is made.

Note that there are no '.0' releases!  I.e. ".0" is only used as a
separator between initial major releases and the first minor release,
and between initial minor releases and the first patch release.

Ideally patch releases will be developed on a release branch to permit
parallel development of new features on the trunk for the next minor (or
major) release (with folding of fixes and features as necessary back to
the trunk).  In theory minor releases could also be developed on release
branches, but only in situations where extreme levels of maintenance for
existing releases must be undertaken.

You'll note this effectively caps the maximum patch level, and the
maximum minor release number, to a ceiling of ".79", and limits the
number of alpha releases to just 10.  Unfortunately it does not limit
the number of beta releases since things like .100 are allowed!  ;-)

If you see "-Preview" appended to the release number then you're seeing
an intermediate development copy -- i.e. an as-yet un-released copy
which will likely have the release number given with the suffix stripped
when it is finally officially released.
----------------------------------------

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>