HEADS-UP: Library version number bumps

[Kris Kennaway]

On Wed, Sep 29, 2004 at 08:36:45PM -0400, Daniel Eischen wrote:
> On Wed, 29 Sep 2004, M. Warner Losh wrote:
> 
> > In message: <Pine.GSO.4.43.0409291006430.13426-100000 at sea.ntplx.net>
> >             Daniel Eischen <deischen at freebsd.org> writes:
> > : 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.
> >
> > In a lot of respects I like this idea.  However, the unanswered
> > question would be how to implement it.  The bumps are easy to do (the
> > version number is basically meaningless), but frequeny bumps have
> > issues as well.  Laying those aside for the moment, my concern is how
> > do we do the 'one release comes' part there.  How do we know if they
> > are binary compatible or not?  Wouldn't this tend to encourage people
> > to make binary incompatible libraryes?
> 
> It doesn't solve the current problem of knowing if changes
> break ABI.  It is also still up to the committers to both
> avoid introducing any uncessary ABI breakages and to review
> other committers' changes.

That hasn't worked very well during the 5.x branch, as the current
thread (and previous iterations of it) show.  All I was able to look
for were incompatible changes to the symbol table; other types of
breakage like incompatible changes to function interfaces and data
structures are much more difficult to detect.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20040929/9c2358fa/attachment.bin