From owner-cvs-all@FreeBSD.ORG Tue Dec 18 12:32:21 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 B697A16A417; Tue, 18 Dec 2007 12:32:21 +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 4DFDB13C45D; Tue, 18 Dec 2007 12:32:21 +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.2/8.14.2/NETPLEX) with ESMTP id lBICWJvS001080; Tue, 18 Dec 2007 07:32:20 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 18 Dec 2007 07:32:20 -0500 (EST) Date: Tue, 18 Dec 2007 07:32:19 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alfred Perlstein In-Reply-To: <20071218100012.GQ16982@elvis.mu.org> Message-ID: References: <200712142049.lBEKn7RJ018896@repoman.freebsd.org> <200712171419.06759.jhb@freebsd.org> <20071218100012.GQ16982@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, John Baldwin Subject: Re: cvs commit: src/lib/libc Versions.def X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2007 12:32:21 -0000 On Tue, 18 Dec 2007, Alfred Perlstein wrote: > * Daniel Eischen [071217 17:42] wrote: >> On Mon, 17 Dec 2007, John Baldwin wrote: >> >>> On Friday 14 December 2007 03:49:07 pm Daniel Eischen wrote: >>>> deischen 2007-12-14 20:49:07 UTC >>>> >>>> FreeBSD src repository >>>> >>>> Modified files: >>>> lib/libc Versions.def >>>> Log: >>>> Increment the version namespace for 8.0-current. New symbols and >>>> symbols whose ABI has changed should be added to FBSD_1.1. >>> >>> Why do new symbols have to be added to 1.1 instead of 1.0? >> >> There is no technical reason they cannot be, but this is what we >> decided some time ago. That each time head is branched, a new >> version is created and new and ABI-changed symbols get added to >> it. It makes it easy to track when (initially in which major >> FreeBSD version) symbols get added. I should have also noted >> that this was discussed with kan and das (not des) prior to >> commit. kan's other comment was that this would also make it >> easier to write tools that can tell if an application built on >> release X can run on release Y (where Y < X). >> >> We can still MFC new symbols back to prior releases, we just >> have to add them to the same namespace from which they came. > > Daniel, is there anything preventing us from matching version > numbers with release numbers? This would make things a bit > more intuative. This was already discussed before. I do not think it is a good idea - it is easy to create a lookup table matching version numbers to release numbers if that is needed for ABI checking tools, and simple comments in the version defs file makes it apparent to anyone looking at it. I don't think we want to tie release numbers to version numbers, and when you backport changes, it makes it confusing because you now have FBSD_8 symbols in releng_7. Other packagers may also not be using the same release numbering scheme that the project uses. Sun for instance does not name their versions after releases, they use SUNW1.0, SUNW_1.1, etc. Also, there may be multiple ABI changes in HEAD that warrant bumping the version number more than once (akin to bumping library versions, but this hasn't yet happened in the past). There would be no corresponding release to match, but you would have to bump the version number regardless. The version numbering is not something that is easily visible to the user. It is simpler and more flexible to avoid tying version numbers to release numbers, and to write ABI checking tools (easily done with scripts) to do what we need. -- DE