cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h
John E Hein
jhein at timing.com
Sun Aug 26 05:36:08 PDT 2007
Yar Tikhiy wrote at 09:33 +0400 on Aug 25, 2007:
> 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.
> 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.
By way of precedent, this reminds me of how __FreeBSD_version is used
for miscellaneous intra-release changes (changes that aren't
necessarily ABI changes, but perhaps disappearance or emergence of new
tools or tool changes). For instance, this has been known to happen
when the pkg* tools change and the ports infrastructure is tweaked to
behave differently based on the fine-grained FreeBSD version (aka
Can the symbol versioning labels be standardized to make similar
accomodations for ABI changes in between releases?
Even in stable branches, now that I think about it. I almost removed
that controversial thought from this email to avoid a flame war. But
on the other hand, used conservatively, I could foresee a security fix
being made much easier if an ABI change was allowed. This would be
quite rare, I'm sure.
More information about the cvs-all