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

[M. Warner Losh]

In message: <20070828023857.GW21352 at comp.chem.msu.su>
            Yar Tikhiy <yar at comp.chem.msu.su> writes:
: 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. :-)

How is this a natural consequence of this policy?  If one were to
bump twice, how would that break it?

Warner