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

[John Baldwin]

On Monday 27 August 2007 02:39:26 pm Daniel Eischen wrote:
> > 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 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).

I agree, but I see fbsd-current for non-released symbols (changes in HEAD that 
aren't in a release yet) as a compromise that let's the "real" symbols follow 
this path.

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

Ok, I can live with tossing the 7.0 renumber.  However, what about the larger 
picture (ignoring specific numbers) of allowing for the future by using a 
separate namespace (fbsd-current) for ABI changes that happen in HEAD and 
only promoting those symbols into the "real" fbsd namespace when a RELENG_X 
branch is branched?  This preserves the desired behavior of the "real" 
symbols and allows us to not keep a lot of compat gunk around for versions of 
symbols that were never released (at least not in the releases) while still 
giving other folks a slightly less rough-edged -current when navigating the 
various ABI breakages.

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

The key thing I think is ease-of-use for developer vs ease-of-use for for 
users on the branch.  AFAIK, ELF major numbers for shared libs didn't allow 
us a way to provide a private version space for unreleased ABI changes in 
HEAD, so we just lived with the pain of a single bump per HEAD cycle in the 
past.  Now that there is a more fine-grained tool that does allow for things 
like a private version space for HEAD, there are folks who want to take 
advantage of it to help out with the ease-of-use for running -current on 
systems.

My primary concern is that we find a way to minimize the amount of compat 
shims in the releases to the bare minimum needed to reduce future 
maintenance, etc. costs.  I think having a private namespace for unreleased 
symbols in HEAD can give us that (in RELENG_X branches we only 
have "released" symbols, and in HEAD we phase out private compat symbols on 
whatever schedule seems suitable) while still letting folks use symbol 
versioning to make HEAD a little less rough-edged.

-- 
John Baldwin