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

[Yar Tikhiy]

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

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.

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

-- 
Yar