Re: HEADS-UP: Library version number bumps

On Wed, 29 Sep 2004, Ken Smith wrote:

> On Wed, Sep 29, 2004 at 07:27:10PM +1000, Tim Robbins wrote:
> > On Tue, Sep 28, 2004 at 11:05:46PM -0400, Ken Smith wrote:
> > >
> > > >From the "Better late than never" Department...
> > >
> > > It looks like we should probably bump the version of a couple of
> > > the system libraries.  With LOTS of help from Kris it looks like
> > > this is the list we think needs a version bump, with the version
> > > from 4.X being placed in compat4x:
> > >
> > >        libgnuregex.so.2
> > >        libhistory.so.4
> > >        libm.so.2
> > >        libncurses.so.5
> > >        libopie.so.2
> > >        libpcap.so.2
> > >        libreadline.so.4
> > >        libwrap.so.3
> > >
> > > The bumps will be coming soon...
> >
> > Why do they need to be bumped? Why use the version from 4.x? It sounds like
> > this will break a lot of 5.x binaries.
> >
>
> They need to be bumped because the internal workings of the libraries
> have changed in such a way that a 4.X executable will either be
> un-dynamically-linkable, will fail ungracefully (seg-fault, etc),
> or (worse) run but it makes assumptions that are no longer valid
> thus producing incorrect results.  By putting the older versions of
> the libraries in the compat directory the dynamic linker will find
> and link to those instead when starting the executable and since we
> will have taken them from a 4.X system the executable should run just
> fine.
>
> Normally development cycles are "much more sane" (Scott's usual phrasing
> for it :-) so at least in theory they're much shorter, and we don't
> usually have as many "end-user-type-people" using a development branch
> as we have now with the 5.X series.  So the fact we do this sort of thing
> hasn't been a huge issue before - the developers should know how to cope
> with it.  You're right - there can be 5.X based binaries that will have
> problems.  At this point we need to decide which old executables break
> and we're opting to break the 5.X executables - at least those users
> had a little bit of a warning they were using a not-for-production-use
> system.  We're not particularly happy about needing to do this.

This has been mentioned before, but when breaking (or potentially
breaking) ABI, can we bump the version numbers to libfoo.YYYYMMDD?
Once release comes, we can move them back to SHLIB_MAJOR + 1 (or
even decide to keep them at SHLIB_MAJOR if ABI wasn't really broken).
This helps folks running HEAD so they can update their ports over time.

-- 
Dan Eischen