From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 00:36:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09D8216A4CE; Thu, 30 Sep 2004 00:36:57 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB4DD43D1F; Thu, 30 Sep 2004 00:36:56 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i8U0ak03014217; Wed, 29 Sep 2004 20:36:46 -0400 (EDT) Date: Wed, 29 Sep 2004 20:36:45 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20040929.174914.05878370.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: kensmith@cse.Buffalo.EDU cc: tjr@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: HEADS-UP: Library version number bumps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Thu, 30 Sep 2004 00:36:57 -0000 On Wed, 29 Sep 2004, M. Warner Losh wrote: > In message: > Daniel Eischen writes: > : This has been mentioned before, but when breaking (or potentially > : breaking) ABI, can we bump the version numbers to libfoo.YYYYMMDD? > : Once release comes, we can move them back to SHLIB_MAJOR + 1 (or > : even decide to keep them at SHLIB_MAJOR if ABI wasn't really broken). > : This helps folks running HEAD so they can update their ports over time. > > In a lot of respects I like this idea. However, the unanswered > question would be how to implement it. The bumps are easy to do (the > version number is basically meaningless), but frequeny bumps have > issues as well. Laying those aside for the moment, my concern is how > do we do the 'one release comes' part there. How do we know if they > are binary compatible or not? Wouldn't this tend to encourage people > to make binary incompatible libraryes? It doesn't solve the current problem of knowing if changes break ABI. It is also still up to the committers to both avoid introducing any uncessary ABI breakages and to review other committers' changes. I suppose 'Once release comes' is when we're getting ready for release and the re@ team lays the tag and freezes the branch. At that point, you move the version numbers back in both the branch and HEAD. re@ comes out and says "Try to avoid any major changes to HEAD until after release" which implies "no more shared library ABI changes". I know there will be some ABI changes in 6.0, libc for sure. If we go directly from libc.so.5 to libc.so.6 after the first ABI change, that hoses -current folks when the next libc ABI change hits the tree and you don't bump the version number again. -- Dan Eischen