[PURRS-devel] ABIisms (Was: PATCH: remove_all() method added to the containers)

[Richard B. Kreckel]

Hi,

On Sun, 20 Jan 2002, Roberto Bagnara wrote:
[...]
>   public:
>   	virtual ${CONTAINER} & append(const ex & b);
>   	virtual ${CONTAINER} & remove_last(void);
> + 	virtual ${CONTAINER} & remove_all(void);
[...]

This changes lst's vtable layout and is therefore likely to break binary
compatibility.  Whatever is decided on this, we should not put it in CVS
for this reason.

Until November we have not been nice to people w.r.t. compatibility.  I
hope we manage to be a little bit more civilized from now on.  The scheme
I am having in mind is currently this:
  During 1.0.n, don't break binary compatibility, i.e. never set
  BINARY_AGE to zero.  (Of course, INTERFACE_AGE may be set to zero,
  though.)  Accumulate such paches as the above or Douglas' safe_bool
  and throw them all into 1.1.0.  Repeat the game for 1.1.n.

I know how to handle my libraries and others may know also, but let's face
it: this stuff is somewhat advanced and we don't want to run around and
explain LD_PRELOAD and friends to the people.  It also helps package
maintainance on distro-side as a whole.  Because then, a package libginac0
bringing with it the file $prefix/lib/libginac-1.0.so.0.2.1 can live on
its own and have other packages depend on it and later on a package
libginac1 can be added and just adds $prefix/lib/libginac-1.1.so.1.0.0 but
does not replace the old library.  That one can be phased out when no
other packages depend on it downstream.  Dazed and confused?  Hmm, shared
library management tends to confuse people but the libtool scheme can
potentially solve all the problems, so let's enforce it a bit.

Now the real question is: How do we introduce branches in our CVS tree?

Regards
     -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>