HEADS-UP: Library version number bumps
kris at obsecurity.org
Wed Sep 29 17:43:53 PDT 2004
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20040929/9c2358fa/attachment.bin
More information about the freebsd-current