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.0708271338230.28508 at sea.ntplx.net>
>            Daniel Eischen <deischen at freebsd.org> writes:
>
> : 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.

I was talking about the _symbol_ versions being bumped in the latter
part of that, not the _library_ version.  When I said "less often
than libraries", I meant before symbol versioning.  I agree that
after symbol versioning we ought not to be bumping library versions.

> 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.

You only need to bump symbol versions once when the first ABI change
occurs, and after that, only again when an ABI from the second
version changes.  There's no need to bump for the sake of bumping,
and it doesn't really buy us anything except confusing us with more
version namespaces.

I think we need to separate the version namespace from releases,
with the caveat we only care about the symbols that we export from
a release, not intermediate steps.  If we want a way to list the
symbols from a release, we can do that with other tools or autogenerate
a file that is committed everytime we add symbols to a version.
Having versions tied to releases will just make it harder for us
to maintain, especially when you think about maintaining 2 or 3
branches at once (RELENG_7, RELENG_8, and RELENG_9).

> : 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.

I have to disagree pretty heavily here.  Symbols shouldn't be tied
to a release.  Especially when you start to backport changes to
previous branches.  When you backport changes to previous branches,
now you are going to have FBSD_8.0 symbols in FBSD_7.0.  Thinking
about the symbol namespace this way isn't what you want, and if
you think off in to the future, you'll see that you'll start
having the same set of functions (with same ABI) appearing in
multiple versions.

It is much easier to change the ABI version once when the first
ABI change occurs, and only ever change it again when an ABI
from the current (ABI) version changes.

-- 
DE