From owner-cvs-all@FreeBSD.ORG Tue Aug 28 03:49:36 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 886DE16A417; Tue, 28 Aug 2007 03:49:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2618913C45A; Tue, 28 Aug 2007 03:49:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l7S3lR9s007679; Mon, 27 Aug 2007 21:47:27 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 27 Aug 2007 21:47:31 -0600 (MDT) Message-Id: <20070827.214731.635732686.imp@bsdimp.com> To: yar@comp.chem.msu.su From: "M. Warner Losh" In-Reply-To: <20070828023857.GW21352@comp.chem.msu.su> References: <20070828004842.GT21352@comp.chem.msu.su> <20070828023857.GW21352@comp.chem.msu.su> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 27 Aug 2007 21:47:27 -0600 (MDT) 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 03:49:36 -0000 In message: <20070828023857.GW21352@comp.chem.msu.su> Yar Tikhiy 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? Warner