From owner-cvs-src@FreeBSD.ORG Tue Aug 28 09:12:11 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91A7A16A41B; Tue, 28 Aug 2007 09:12:11 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id D670813C4DE; Tue, 28 Aug 2007 09:12:10 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l7S9BtX4091678; Tue, 28 Aug 2007 13:11:55 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l7S9BsoC091677; Tue, 28 Aug 2007 13:11:54 +0400 (MSD) (envelope-from yar) Date: Tue, 28 Aug 2007 13:11:54 +0400 From: Yar Tikhiy To: "M. Warner Losh" Message-ID: <20070828091153.GZ21352@comp.chem.msu.su> References: <20070828004842.GT21352@comp.chem.msu.su> <20070828023857.GW21352@comp.chem.msu.su> <20070827.213424.1678771352.imp@bsdimp.com> <20070828083736.GX21352@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070828083736.GX21352@comp.chem.msu.su> User-Agent: Mutt/1.5.9i 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 09:12:11 -0000 On Tue, Aug 28, 2007 at 12:37:36PM +0400, Yar Tikhiy wrote: > On Mon, Aug 27, 2007 at 09:34:24PM -0600, M. Warner Losh wrote: > > In message: <20070828023857.GW21352@comp.chem.msu.su> > > Yar Tikhiy writes: > > : > > : 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? > > If we bump a symbol twice or more times between a pair of major > releases while preserving its older versions for compatibility, > we'll have to decide what to do with the intermediate versions > later. If we keep them forever in the same manner as released > versions are going to be kept, CURRENT users will be able to use > ports built any time, exactly as in the above case. But, with a > lot of such unreleased versions accumulated in the library, their > support can need considerable efforts, e.g., if a security hole in > all versions of the symbol is found. Perhaps we'll have to prune > away the oldest unreleased versions periodically, but then some > people will have to rebuild their old ports. Not a big deal, but > the smoothness is lost to some extent. Another caveat of these two policies came to my mind. What to do with the old intermediate versions of symbols when the next RELENG_X is branched? For pure STABLE and RELEASE users they are nothing but dead code, so it would make sense to remove them from the branch. OTOH, dropping them will create a pain for those who gets tired of CURRENT and decides to take a turn to the new STABLE branch because ports linked against the dropped versions will need a rebuild. But, upon a second thought, so we'll bind such people to CURRENT forever and prevent their desertion. :-) -- Yar