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

[M. Warner Losh]

In message: <Pine.GSO.4.64.0708271419060.28508 at sea.ntplx.net>
            Daniel Eischen <deischen at FreeBSD.ORG> writes:
: > 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 must disagree.  Smoothing out the bumps in current is a very
tangible benefit.  And I don't see what the confusion would be.  It
would be very clearly defined that these are 'bridges' that we remove
after so long, use for so long ,etc.

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

That's fine.  s/7.0/2.0/g in all my stuff.  And if people notice, and
chances are they will not, a simple explanation will suffice.  We'll
have to explain anyway if they notice that we're at revision 1.0 for
FreeBSD 7.0. 

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

Is your disagreement with 7.0 or with the whole concept?  If it is
just 7.0, s/7.0/2.0/g.  We could then tell people the 1.x revisions
were for testing purposes only and were removed before the release...
Since it is just an arbitrary string, it can be anything we want it to
be.

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

Easier for the developer making the change.  Harder for everybody
else.  We need a balance here so that we can smooth out the bumps in
-current because ports/packages have become so complex and difficult
to build/rebuild that some aid is needed.  Developers are going to
have to do the bump anyway when they make an incompatible change, so
why not make them do it for all incompatible changes?  Its not like
we're going to be changing exported symbols that many times between
releases.  But since we have the means to remain compatible to ease
the bumpiness of current, why can't we at least consider the
possibility?

Warner