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

[M. Warner Losh]

In message: <Pine.GSO.4.64.0708271338230.28508 at sea.ntplx.net>
            Daniel Eischen <deischen at freebsd.org> writes:
: On Mon, 27 Aug 2007, M. Warner Losh wrote:
: 
: > In message: <200708270932.31208.jhb at freebsd.org>
: >            John Baldwin <jhb at freebsd.org> writes:
: >
: > : Just as with
: > : shared libraries, we version the ABIs in releases and stable branches.
: > : We have _never_ versioned ABI changes in HEAD because HEAD is a tumultuous
: > : place and having the ABIs change multiple times in a branch w/o having
: > : multiple version bumps is just part of running HEAD.
: >
: > We've never versioned ABIs in head because we've never had the ability
: > to do so in a non-disruptive way.  Also, this isn't the "wild west"
: > head of our forefathers.  We're not at some arbitrary point in the
: > evolution of FreeBSD, but in a code freeze getting ready to do a release.
: 
: And the fact that we're in a code freeze should prohibit changes
: like this from going in.

But the rules have changed with symbol versioning.  They give us the
ability to do things we've never done before.  They are a powerful
tool that can be used to make current a less bumpy place, and that
potential shouldn't be dismissed out of hand because we've never done
that before.  The reason we've never done it before is that we didn't
have the tools to make it easy to do it before.

: The rule has been that we only bump libraries once between releases.
: The same thing will hold true for versions; they'll only be bumped
: at most once between releases, and in fact will probably be bumped
: _much_ less often that libraries.

Libraries with version symbols should never be bumped again, unless
there is a real binary compat issue.  Typically, I'd guess that we'd
need to bump versions of symbols only every couple of releases.
FreeBSD only recently started bumping all the shared libraries major
number as a precaution because we couldn't maintain binary
compatibility.  Symbol versions will give us tools to help with that,
but we do still need to be careful.

: There is no overwhelming reason to break the rules that we've held
: in the past.  It's easy to say, "but it's less painful", but after
: you've gone through it, you're done.  I think we're taking a very
: short-sighted view of things and don't agree with breaking or bending
: the rules without a _very_ good reason.

I think the reasons have been well presented so far.  However, there's
a way we can cope without having to break the world or our rules.
BTW, we never agreed what to do about symbol versions in current, so
there's really no rules to break.  Consensus never was reached on what
to do there, although you keep asserting that we can only bump them
once, but that has never been agreed to and codified.  There is strong
agreement that we only have user visible changes once per release, but
a divergence of views on what to do in current.  However, there's a
strong desire to use it to make -current a less bumpy place.  This
thread is clear evidence of that.

However, there's a forth option that I'd not considered.  It goes like
so.  Thanks to John Baldwin, Brooks Davis, Ken Smith and kan for
hammering out the details on IRC.  This is just a proposal, but we
think a good one that will solve the problems.

FBSD-1.0 is the 'current' branch.  We put the new fts symbols in as
FBSD-1.1.  If there are other things that require binary bumps between
now and "the release" we do the same for them.  chances are good there
won't be any, but you never know when a security issue will come up
that needs to do a ABI change.  This will give us both a dry-run for
having multiple versions of symbols, as well as practical experience
for how to make -current less bumpy in the future.

Somewhere around RC1, we change all the symbols to be FBSD-7.0.
There's no reason why we have to start at 1.0, and the disconnect
between major release and ABI version seems artificial to me.
Changing all the symbols near RC1 time would give all the ports
builders a chance to shake out that process.  Portmgr has stated that
they want an RC1 from re@ about a month before the final release so
they can do all the builds and work out whatever issues come up.  It
would give people a good point where packages are available to cope
with the requirement to rebuild everything.  It would also let us
remove the compat hacks after the release in HEAD and before the
release in RELENG_7.  We can also keep the FBSD-1.x symbols around
long enough for people to do the upgrades.

I put "the release" in quotes because the release engineer gets to
make the call when he wants to finally freeze things for the release.
If that's RC1 great.  If that's BETA1, great.  If it is later, that's
good too.  We should allow him to make the call on the timing, since
he has to coordinate the release with a lot of different people.

Warner