Re: HEADS-UP: Library version number bumps

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.

I suppose 'Once release comes' is when we're getting ready
for release and the re_at_ team lays the tag and freezes the
branch.  At that point, you move the version numbers back
in both the branch and HEAD.  re_at_ comes out and says "Try
to avoid any major changes to HEAD until after release"
which implies "no more shared library ABI changes".

I know there will be some ABI changes in 6.0, libc for sure.
If we go directly from libc.so.5 to libc.so.6 after the first
ABI change, that hoses -current folks when the next libc ABI
change hits the tree and you don't bump the version number
again.

-- 
Dan Eischen