HEADS-UP new statfs structure

M. Warner Losh imp at bsdimp.com
Sat Nov 15 22:20:39 PST 2003

In message: <p06002018bbdca66d3d67@[]>
            Garance A Drosihn <drosih at rpi.edu> writes:
: At 6:20 PM -0800 11/15/03, David O'Brien wrote:
: >On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
: >>  Provided that we
: >  > 2. replace the date with a convenient sequence number,
: >  >    which we can call the minor version number, and
: >..
: >  > E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...
: >
: >Please no -- it wouldn't be easy to see a.out libs from ELF ones.
: >(yes I still have some a.out binaries)
: Maybe:
:     libc.so.6.e0, libc.so.6.e1, and (first release) libc.so.6.e2...
: I have no idea what would be best to do, but I do think we
: (developers and users alike) would be much better off if
: we had some way to handle all these changes which come in.
: Or maybe the real problem is that we claim that there will
: be no API/ABI changes after X.0-RELEASE, and we've really
: missed that mark with 5.0-RELEASE, for a variety of reasons.
: If we're going to keep missing that mark with the 6.x-series,
: then we should plan to do something to make life a little
: less painful.  Right now it's getting more painful, if for
: no other reason than we have more developers, and thus more
: major-changes in the pipeline.

Actually, 5.x is an anomaly.  We'd planned on freezing the 5.0 ABI at
5.0, but we missed that mark and are waiting for 5.3 to freeze the
ABI, treaing 5.0, 5.1 and 5.2 as if they were pre-releases.  For 6.0
we'll be back to having libc.so.6.


More information about the freebsd-current mailing list