Re: [Boost-users] Version Mgmt classes/algorithms

From: Rich Johnson (rjohnson_at_[hidden])
Date: 2006-01-26 19:26:50

On Jan 26, 2006, at 11:58 AM, Noel Yap wrote:

> Hmm, I've been thinking about this problem but from a different  
> perspective.
>
> First, some definitions:
> - patch release:  the new component is link and load compatible with
> the old one; clients might need to relink or reload
> - minor release:  the new component is compile compatible with the old
> one; clients might need to recompile
> - major release:  the new component isn't compatible with the old one;
> clients might need to modify code
>
> Given the above, a mapping can be made of changes to source to one of
> the above.  I suppose if a component developer follows the above, one
> could write a class that could easily figure out whether or not a
> certain M.m.p update is backwards compatible with another.
>
> Also, what really counts are changes to header files.  More
> specifically, changes to published header files (ie header files that
> are installed so as to be usable by other components).

I LIKE the crispness of your functional definitions.  They suggest  
that there may exist an algorithm determining the ''order'' of a change:
- Any change in the interface base class is _at least_ a minor release.
- Any change in an implementation derived class is _at most_ a patch  
release.
- Any change in the semantics of the base class interface is _at  
least_ a major release.
- Version stamp can probably be generated by configuration control  
(i.e. CVS);
- Version stamp can probably be used as a _signature_ of the module's  
interface.

FWIW, a "compiler compatibility" is  probably required when dealing  
with separately compiled modules.

Applying the definitions to dynamically loaded libraries where we're  
_always_ relinking; we come up with:
- if patch release; accept
- if minor release; reject  (you _might_ scoot by with some changes;  
but why risk it?)
- if major release; reject
- if compiler incompatible; reject (of course).

Dynamically loaded modules could supply a ''well known'' C function  
to access their version stamp (or otherwise determine compatibility)  
prior to instantiating any dynamically allocated objects.

Now you've got me thinking....
--rich