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.