Date: Tue, 28 Aug 2007 12:43:33 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: "M. Warner Losh" <imp@bsdimp.com> Cc: src-committers@freebsd.org, jhb@freebsd.org, peterjeremy@optushome.com.au, 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: <20070828084333.GY21352@comp.chem.msu.su> In-Reply-To: <20070827.214731.635732686.imp@bsdimp.com> References: <20070828004842.GT21352@comp.chem.msu.su> <Pine.GSO.4.64.0708272127371.28508@sea.ntplx.net> <20070828023857.GW21352@comp.chem.msu.su> <20070827.214731.635732686.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 27, 2007 at 09:47:31PM -0600, M. Warner Losh wrote: > 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. :-) > > Or rather, isn't this just the consequences of the way the script that > generates things works? AFAIK, no. The script isn't that restrictive although it's Daniel who wrote it. :-) I think the script allows us to do almost anything we can do with a plain vanilla version map. It even supports multiple version axes, which is used now to separate standard functions from FreeBSD-specific functions. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070828084333.GY21352>