From owner-cvs-all@FreeBSD.ORG Sat Aug 25 15:40:31 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 56F8616A417; Sat, 25 Aug 2007 15:40:31 +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 E3AE313C459; Sat, 25 Aug 2007 15:40:30 +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 l7PFdLmw070424; Sat, 25 Aug 2007 09:39:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 25 Aug 2007 09:39:25 -0600 (MDT) Message-Id: <20070825.093925.43008968.imp@bsdimp.com> To: yar@comp.chem.msu.su From: "M. Warner Losh" In-Reply-To: <20070825053302.GG99474@comp.chem.msu.su> References: <20070824.172212.74696955.imp@bsdimp.com> <20070825053302.GG99474@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]); Sat, 25 Aug 2007 09:39:22 -0600 (MDT) Cc: src-committers@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: Sat, 25 Aug 2007 15:40:31 -0000 In message: <20070825053302.GG99474@comp.chem.msu.su> Yar Tikhiy writes: : On Fri, Aug 24, 2007 at 11:08:01PM -0400, Daniel Eischen wrote: : > : > It should be easy to say FBSD_1.0 is RELEASE_7.0, FBBSD_1.1 is RELEASE_7.1, : > etc. The versioned symbol namespace is mostly to aid the release : > engineers. If you start to have FBSD_1.2, FBSD_1.3, and FBSD_1.4 : > are interim versions and FBSD_1.5 is release 7.1, that isn't good. : : I've been sure until this thread that symbol versioning removes the : whole need to bump versions artificially before each major release : in favor of natural versioning, when a symbol proceeds along the : version scale only if its properties actually change. That was my understanding as well. The artificial version bump is way lame, but is one of the less bad alternatives. : Old versions : can be removed, e.g., one major release later if needed, but ABIs : change not too often and it may be reasonable to keep old versions : of symbols and forget about separate compat libraries. That's how : I imagined the benefits from symbol versioning. Was I totally wrong? That was my understanding of the promise of symbol versioning. The hard part would be forcing people to make compatible changes all the time to all the libraries that did versioning. : In addition, symbol versions are mere text labels with no special : meaning to ld(1), so we can format them to allow for version changes : between major releases. Agreed. : > Again, I highly doubt you would have Sun or even Linux have interim : > versions that are made public. If you want to have interim versions : > and then remove them at a later point before a release, that is a : > different story, but it doesn't solve the problem for someone missing : > the transition period, whereas a more general solution would. : : Not that I'm pressing you to accept my POV, but it's not the first : time I get into an argument regarding our symbol versioning : implementation and usage, and receive only vague references to Sun : and Linux "not doing this way". It seems high time to define clearly : what _we_ (not Sun, Linux, you, or I) want from that symbol versioning : thing and document it. Also agreed. We're FreeBSD. We are tool users. We should use tools in a way that makes sense for us. Solaris' and Linux's experiences with versioning should inform our policies, there is no doubt, but since I don't think I've seen either written down in exacting detail that we can just import, there does need to be at least some effort to write up what the party line is. Warner