Date: Mon, 27 Aug 2007 21:34:24 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: yar@comp.chem.msu.su Cc: src-committers@freebsd.org, jhb@freebsd.org, alfred@freebsd.org, cvs-all@freebsd.org, deischen@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <20070827.213424.1678771352.imp@bsdimp.com> In-Reply-To: <20070828023857.GW21352@comp.chem.msu.su> References: <20070828004842.GT21352@comp.chem.msu.su> <Pine.GSO.4.64.0708272127371.28508@sea.ntplx.net> <20070828023857.GW21352@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20070828023857.GW21352@comp.chem.msu.su>
Yar Tikhiy <yar@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@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@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070827.213424.1678771352.imp>