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

[Yar Tikhiy]

On Mon, Aug 27, 2007 at 09:30:48PM -0400, Daniel Eischen wrote:
> On Tue, 28 Aug 2007, Yar Tikhiy wrote:
> >
> >Example: Assume we released 7.0-R with all symbols at FBSD_1.0.
> >Before the 8.0 release cycle starts, struct FTS and struct FILE
> >change, perhaps a few times each, thus affecting the fts(3) and
> >stdio(3) global symbols.  At the very first change to a symbol or
> >their group, its 7.0-R variant is preserved at FBSD_1.0 and its
> >default version becomes FBSD_1.1.  Later changes to the current
> >variant of that symbol don't affect its version.  Consequently,
> >8.0-R is released with the new fts(3) and stdio(3) symbols at
> >FBSD_1.1, their 7.0-R variants at FBSD_1.0, and the rest of symbols
> >still at FBSD_1.0 because they are unchanged.  Let's note that
> >CURRENT users had to rebuild ports depending on fts(3) or stdio(3)
> >_each time_ an ABI component changed.
> 
> I think you're a little confused here.  CURRENT users did NOT have
> to rebuild ports when fts(3) or stdio(3) ABIs changed.  They
> would only have to rebuild if one of these ABIs changed _more
> than once between releases_.  That hasn't ever happened to my
> knowledge in the past, and it really shouldn't happen as long
> as things are tested and reviewed properly.

Oh, indeed!  If a user builds an ABI-dependent port before the
change, the port will record dependence on say fwrite at FBSD_1.0.  In
our example, the default version of fwrite() and friends will change
to FBSD_1.1 later, after 7.0-RELEASE is out, but fwrite at FBSD_1.0
will also stay as a compatibility version because it appeared in
the previous release.  Moreover, the port will still work even if
the ABI component changes once more after 8.0-RELEASE and proceeds
to FBSD_1.2, because fwrite at FBSD_1.0 will be there.  Similarly, a
port built between 7.0-R and 8.0-R will work after the 2nd change
as fwrite at FBSD_1.1 will be there, too.

I can't but remark that this is not a natural effect of symbol
versioning, but a consequence from the following policy:

- At most one new version is introduced between major releases.
- Symbol modifications during the period are assigned to the new version.
- There is exactly one change per symbol per version.
- All old symbol versions created so far are preserved.

Now we have at least one policy with known behavior. :-)

-- 
Yar