From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 18:03:39 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABBC916A417 for ; Sun, 26 Aug 2007 18:03:39 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5869813C459 for ; Sun, 26 Aug 2007 18:03:39 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l7QI3NlP015909; Sun, 26 Aug 2007 14:03:23 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Sun, 26 Aug 2007 14:03:23 -0400 (EDT) Date: Sun, 26 Aug 2007 14:03:23 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20070826.113017.-126689373.imp@bsdimp.com> Message-ID: References: <20070826073535.GD21352@comp.chem.msu.su> <20070826.113017.-126689373.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: yar@comp.chem.msu.su, kensmith@cse.Buffalo.EDU, current@freebsd.org Subject: Re: Symbol versioning conventions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2007 18:03:39 -0000 On Sun, 26 Aug 2007, M. Warner Losh wrote: > In message: > Daniel Eischen writes: > : On Sun, 26 Aug 2007, Yar Tikhiy wrote: > : > > : > But, anyway, there are at least three people in the project who > : > misundertood the intended role of symbol versioning. Besides yours > : > truly, a humble developer, there are a core team member and a release > : > engineer among them. This may be a sign that some decisions regarding > : > symbol versioning, which is a rather central feature for developers > : > and code contributors, haven't had enough exposure. Perhaps we've > : > just missed some important discussions on the lists, but symbol > : > versioning is a long-term feature and as such it deserves a document > : > describing in detail how to use it in our project. > : > : I've think I've stated in replies to commit mail that symbol versioning > : isn't meant as a crutch to aid -current developers, but that is neither > : written down or documented and was probably over a year ago. > > You never answered my point: The release engineer gets to decide when > the ABI is frozen. Maybe it already is and this use isn't a crutch. There can be only one ABI or version in a release. Having multiple _new_ versions between releases implies you are using the intermediate versions as a crutch ;-) In this case, it may be a little different because we haven't yet released anything with symbol versioning. The other thing to remember is that we did bump library versions, so any ABI changes are for free (excluding the upgrade pains typically felt by -current developers). If you keep the old FTS and compat functions, you are maintaining them and keeping the old files in the tree when they've never ever seen a release - there is no point in maintaining them _other_ than to aid -current developers. They certainly don't help applications built in 5.x or 6.x. -- DE