cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

[Daniel Eischen]

On Mon, 27 Aug 2007, M. Warner Losh wrote:

> In message: <Pine.GSO.4.64.0708272127371.28508 at sea.ntplx.net>
>            Daniel Eischen <deischen at freebsd.org> writes:
> : I think you're a little confused here.  CURRENT users did NOT have
> : to rebuild ports when fts(3) or stdio(3) ABIs changed.  They
> : would only have to rebuild if one of these ABIs changed _more
> : than once between releases_.  That hasn't ever happened to my
> : knowledge in the past, and it really shouldn't happen as long
> : as things are tested and reviewed properly.
>
> One of the reasons that it hasn't happened before is that we forced
> people who tried to make, or proposed making, such changes to make
> them in a compatible sort of way.  We have all kinds of ugliness in
> and around FILE to try, alas in vain, to be compatible.  One of the
> reasons people would like to see symbol versioning is to make it
> easier to change the size of different structures because we have
> stood on our heads in the past to not change sizes.
>
> I'm concerned that the empirical evidence from the past might not be a
> good thing to base our future plans upon.  We knew we had sucky tools
> to deal with binary incompatibility in the past, so we stood on our
> heads to not make too many binary incompatible changes.  With that
> limitation gone, I think the likelihood is large we will see multiple
> ABI changes between major releases on something.  Especially since it
> happens when structures change size and there are many functions that
> take pointers to multiple structures...

The emphasis should be on trying to get things right, tested, and
reviewed the first time ;-)  But also to keep compat shims to a
minimum too.  It may be easier to create different versions and
keep compatibility, but the SV'd libraries are going to grow with
compat shims if we don't try to reduce ABI changes like we've
done in the past.  I think we need an ABI review board monitored
by -standards ;-)

If you are really concerned about it (I'm not!), then you can
always add another version in between releases, or just bump
the version every time you break an ABI in -current.  I'm not
advocating this because I don't think it's necessary.  I don't
think you need to have both private and public versions in
-current, just use 1.x and bump x for every ABI change.  -current
will always have all versions 1.0 - 1.x, and prior branches
will have some of them.  Whenever -current is branched, both
the branch and -current will once again have all versions
until the ABI in -current changes again.

-- 
DE