[BuildTools] Libtool library versions (was warning re. Lapack 1.0.20)

[Lou Hafer]

Stefan, Ted,

	I'm going to post this to BuildTools for future reference and a heads-up 
to PMs.

	I fully agree that libtool library version numbers (llv) do not make 
much sense for stable and trunk.
	
	The notion that generation of the llv should be handled automatically by
prepare_new_release was what got me into this whole bit with PROJECTDIR_INIT.
Also why I wanted to change stable/0.6/coin.m4 while there was still time.  Now
I have a uniform target to work with:  PROJECTDIR_INIT(Proj) in a stable branch
transforms to PROJECTDIR_INIT(Proj,llv) in a release.

	Stefan, to answer your question:  In a stable branch, just use
PROJECTDIR_INIT(Proj).  In terms of lapack 1.0.21, I think an llv of 1:21:1 is
surely safe.  Really, 1:21:21 would probably be safe, unless there's something
in the Lapack revisions that's not backward compatible.  Ted, it's almost
inevitable that we will go through a period where some projects have llv's and
others do not, but I agree we should approach it cautiously.  Lapack might be as
good a place as any to look for consequences; it's shown us one already.

	Quick recap of llv's: current:revision:age, where

  * current is the current interface (API) number
  * revision is the implementation of the current API
  * age is backward compatibility, i.e., changes between current and
    (current - age) are strictly augmenting, so older code still works.
    
Coin versioning is MM.mm.pp (Major, minor, patch or revision)

If you take the convention that a change in minor version number represents a
backward-compatible API change and a change in major version number represents a
non-backward-compatible API change then you get the scheme that Ted set up in
prepare_new_release:

  * current is the total number of stable branches in the repository
  * revision is the number of releases within a stable branch
  * age is the number of stable branches within a major version.

Coin policy for when to create a new major or minor version is fairly loose, in
keeping with our overall philosophy (`Enhancements that don't do major violence
to the API increment the minor number.')  which I figure is a good thing.  In
terms of the llv, current and revision can be counted and should be reasonably
accurate.  In the implementation I'm working on, I exclude `special purpose'
stables (BSP stables, for example).  Arguably, revision can be precisely the
patch number, if we're willing to tolerate the occasional off-by-one error.  Age
is the tricky one and will definitely require provision for an override.  Since
it should also be possible to override the entire llv, might as well allow an
override for each of current, revision, and age, as well as an option to
suppress the llv entirely.  Suppression will be the default at first; we can
change that when we're ready to phase in llv's across the board.

	That's the plan, as it exists in my head. Your head may differ  :-)
Fortunately, you have 10 days to object before I'll be back at work on this.

							Lou