From owner-cvs-all@FreeBSD.ORG Sat Aug 25 05:33:08 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 7CE0C16A41A; Sat, 25 Aug 2007 05:33:08 +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 C089A13C461; Sat, 25 Aug 2007 05:33:07 +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 l7P5X311015135; Sat, 25 Aug 2007 09:33:03 +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 l7P5X3na015128; Sat, 25 Aug 2007 09:33:03 +0400 (MSD) (envelope-from yar) Date: Sat, 25 Aug 2007 09:33:03 +0400 From: Yar Tikhiy To: Daniel Eischen Message-ID: <20070825053302.GG99474@comp.chem.msu.su> References: <20070824215515.GF16131@turion.vk2pj.dyndns.org> <20070824220244.GH87451@elvis.mu.org> <20070824.172212.74696955.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: src-committers@freebsd.org, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, Warner Losh 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 05:33:08 -0000 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. 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? 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. > 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. -- Yar