From owner-svn-src-head@FreeBSD.ORG Thu Jun 4 16:19:54 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CFC91065670; Thu, 4 Jun 2009 16:19:54 +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 1CA798FC15; Thu, 4 Jun 2009 16:19:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n54GHfoE058438; Thu, 4 Jun 2009 10:17:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 04 Jun 2009 10:17:55 -0600 (MDT) Message-Id: <20090604.101755.1493773383.imp@bsdimp.com> To: das@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090604151959.GA26524@zim.MIT.EDU> References: <200906011807.n51I7ccW086812@svn.freebsd.org> <1243880140.25229.23.camel@bauer.cse.buffalo.edu> <20090604151959.GA26524@zim.MIT.EDU> 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 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, kensmith@cse.Buffalo.EDU, bz@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r193241 - in head: . sys/sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 16:19:54 -0000 In message: <20090604151959.GA26524@zim.MIT.EDU> David Schultz writes: : On Mon, Jun 01, 2009, Ken Smith wrote: : > It was noted we're close to running out of numbers we can use before we : > hit code freeze and the branch for the release. Since we're entering : > code slush at the end of today in theory all changes that would warrant : > a bump in __FreeBSD_version are supposed to be done. But it wouldn't : > surprise me if we have one or two or so things that come along between : > now and when we hit code freeze and the branch. So we need to be a bit : > conservative with this. Please be sure to coordinate anything that : > might require a bump in __FreeBSD_version with re@ from now on. If it : > turns out things do come along that require bumps we'll need to "batch : > them up" having one bump represent several changes. : : To avoid this sort of problem in the future, how about adding a : digit to __FreeBSD_version in 9-CURRENT? Admittedly, a lot of the : bumps in 8.X were probably unnecessary, but it's good that people : are being cautious and documenting their incompatible changes. We can avoid this problem by not being so bump-happy. Adding an extra digit was painful when we did it before. A number of subtle things broke (like the output of file). Part of the problem here is that we want to ship FreeBSD 8.0 as '800100' which is just historical convention: * scheme is: Rxx * 'R' is 0 if release branch or x.0-CURRENT before RELENG_*_0 * is created, otherwise 1. We could easily up that to '5' for the release so we have 499 entries. There aren't so many things that depend on this convention in the tree (I couldn't find any in a quick, informal survey). * scheme is: Rxx * 'R' is less than 5 if release branch or x.0-CURRENT * before RELENG_*_0 is created, otherwise 5 or greater. I think is the only change we really need to make. : Better yet, we could automate the process somewhat and use : something like the major version of FreeBSD concatenated with the : SVN revision in lieu of __FreeBSD_version. I think this would be worse. First, external trackers would have difficulty updating this. Second, __FreeBSD_version is used to indicate kernel ABI points (at least recently, this is lame and should be reverted for the RELENG branch, but I digress). Third, ports use it to determine where we are and build things differently. I think this would complicate their lives and make documenting the points more difficult. This is one of those things that I don't think should be totally automated. Warner