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

You have to keep in mind that you probably won't ever have a
problem between releases.  How many times in the past have we
had incompatible ABI changes between releases?  I don't think
we ever have.  I think you're trying to solve a problem that
has never existed.

> : 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 should stay at 1.0.  If you really really want to have a different
version for FTS, then you can have 1.1.  It's no different than 2.0
and 1.0 - you can say 1.0 was for testing.

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

Because you'll end up with versions FBSD_1.1, FBSD_1.5, and FBSD_2.0
in RELENG_7, only because the ABI changes for 1.2, 1.3, 1.4, and
any in between 1.5 and 2.0, were not deemed MFC'able.  And you
could still have a partial set of symbols from 1.1, 1.5, or 2.0
existing in RELENG_7 because some of those symbols were not
MFC'able either.

Please think about what symbol versioning does.  You can have a
lot of ABI changes added to one symbol version without impacting
anyone.  The only time you will have an impact is if you change
the _same_ ABI more than once between versions, and like I said,
I doubt that has ever happened before.  If it ever does, I guess
you could think about bumping twice between releases, or, God
forbid, make -current users rebuild everything once every 10
years (or however often the situation arises).

If you really want to have a separate version namespace for -current,
you could use FBSDcurrent_1.x bumping when needed.  And whenever
you branched -current again, could bump the mainline version
(e.g., FBSD_1.3 -> FBSD_1.4) once for the branch and reset FBSDcurrent_1.x
back to 0 again.  I don't know the details of how you would hide
these temporary or development versions.  The other thing to
remember is that you have to keep a lot of different versions
in the Symbol.map files and MFC'ing them may be difficult since
the numbering scheme is different.  Plus whenever you MFC something,
you have make sure that the symbol maps in -current are properly
adjusted to match because applications from prior releases have
to continue to work on -current.

I just think using more versions than we need is just going to
make it harder on us to maintain and not help anyone running
releases since they aren't going to see the internal numbering
scheme anyway.

-- 
DE