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

[M. Warner Losh]

In message: <20070825053302.GG99474 at comp.chem.msu.su>
            Yar Tikhiy <yar at comp.chem.msu.su> writes:
: On Fri, Aug 24, 2007 at 11:08:01PM -0400, Daniel Eischen wrote:
: > 
: > It should be easy to say FBSD_1.0 is RELEASE_7.0, FBBSD_1.1 is RELEASE_7.1,
: > etc.  The versioned symbol namespace is mostly to aid the release
: > engineers.  If you start to have FBSD_1.2, FBSD_1.3,  and FBSD_1.4
: > are interim versions and FBSD_1.5 is release 7.1, that isn't good.
: 
: I've been sure until this thread that symbol versioning removes the
: whole need to bump versions artificially before each major release
: in favor of natural versioning, when a symbol proceeds along the
: version scale only if its properties actually change.

That was my understanding as well.  The artificial version bump is
way lame, but is one of the less bad alternatives.

: Old versions
: can be removed, e.g., one major release later if needed, but ABIs
: change not too often and it may be reasonable to keep old versions
: of symbols and forget about separate compat libraries.  That's how
: I imagined the benefits from symbol versioning.  Was I totally wrong?

That was my understanding of the promise of symbol versioning.  The
hard part would be forcing people to make compatible changes all the
time to all the libraries that did versioning.

: In addition, symbol versions are mere text labels with no special
: meaning to ld(1), so we can format them to allow for version changes
: between major releases.

Agreed.

: > Again, I highly doubt you would have Sun or even Linux have interim
: > versions that are made public.   If you want to have interim versions
: > and then remove them at a later point before a release, that is a
: > different story, but it doesn't solve the problem for someone missing
: > the transition period, whereas a more general solution would.
: 
: Not that I'm pressing you to accept my POV, but it's not the first
: time I get into an argument regarding our symbol versioning
: implementation and usage, and receive only vague references to Sun
: and Linux "not doing this way".  It seems high time to define clearly
: what _we_ (not Sun, Linux, you, or I) want from that symbol versioning
: thing and document it.

Also agreed.  We're FreeBSD.  We are tool users.  We should use tools
in a way that makes sense for us.  Solaris' and Linux's experiences
with versioning should inform our policies, there is no doubt, but
since I don't think I've seen either written down in exacting detail
that we can just import, there does need to be at least some effort to
write up what the party line is.

Warner