From owner-cvs-all@FreeBSD.ORG Mon Aug 27 18:13:39 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 ECE3016A420; Mon, 27 Aug 2007 18:13:38 +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 ABC0E13C46C; Mon, 27 Aug 2007 18:13:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l7RIAToT003217; Mon, 27 Aug 2007 12:10:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 27 Aug 2007 12:10:33 -0600 (MDT) Message-Id: <20070827.121033.1102529566.imp@bsdimp.com> To: deischen@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <200708270932.31208.jhb@freebsd.org> <20070827.085906.-332187760.imp@bsdimp.com> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 27 Aug 2007 12:10:30 -0600 (MDT) Cc: src-committers@freebsd.org, jhb@freebsd.org, yar@comp.chem.msu.su, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, kensmith@cse.buffalo.edu 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: Mon, 27 Aug 2007 18:13:39 -0000 In message: Daniel Eischen writes: : On Mon, 27 Aug 2007, M. Warner Losh wrote: : : > In message: <200708270932.31208.jhb@freebsd.org> : > John Baldwin writes: : > : > : Just as with : > : shared libraries, we version the ABIs in releases and stable branches. : > : We have _never_ versioned ABI changes in HEAD because HEAD is a tumultuous : > : place and having the ABIs change multiple times in a branch w/o having : > : multiple version bumps is just part of running HEAD. : > : > We've never versioned ABIs in head because we've never had the ability : > to do so in a non-disruptive way. Also, this isn't the "wild west" : > head of our forefathers. We're not at some arbitrary point in the : > evolution of FreeBSD, but in a code freeze getting ready to do a release. : : And the fact that we're in a code freeze should prohibit changes : like this from going in. But the rules have changed with symbol versioning. They give us the ability to do things we've never done before. They are a powerful tool that can be used to make current a less bumpy place, and that potential shouldn't be dismissed out of hand because we've never done that before. The reason we've never done it before is that we didn't have the tools to make it easy to do it before. : The rule has been that we only bump libraries once between releases. : The same thing will hold true for versions; they'll only be bumped : at most once between releases, and in fact will probably be bumped : _much_ less often that libraries. Libraries with version symbols should never be bumped again, unless there is a real binary compat issue. Typically, I'd guess that we'd need to bump versions of symbols only every couple of releases. FreeBSD only recently started bumping all the shared libraries major number as a precaution because we couldn't maintain binary compatibility. Symbol versions will give us tools to help with that, but we do still need to be careful. : There is no overwhelming reason to break the rules that we've held : in the past. It's easy to say, "but it's less painful", but after : you've gone through it, you're done. I think we're taking a very : short-sighted view of things and don't agree with breaking or bending : the rules without a _very_ good reason. I think the reasons have been well presented so far. However, there's a way we can cope without having to break the world or our rules. BTW, we never agreed what to do about symbol versions in current, so there's really no rules to break. Consensus never was reached on what to do there, although you keep asserting that we can only bump them once, but that has never been agreed to and codified. There is strong agreement that we only have user visible changes once per release, but a divergence of views on what to do in current. However, there's a strong desire to use it to make -current a less bumpy place. This thread is clear evidence of that. However, there's a forth option that I'd not considered. It goes like so. Thanks to John Baldwin, Brooks Davis, Ken Smith and kan for hammering out the details on IRC. This is just a proposal, but we think a good one that will solve the problems. FBSD-1.0 is the 'current' branch. We put the new fts symbols in as FBSD-1.1. If there are other things that require binary bumps between now and "the release" we do the same for them. chances are good there won't be any, but you never know when a security issue will come up that needs to do a ABI change. This will give us both a dry-run for having multiple versions of symbols, as well as practical experience for how to make -current less bumpy in the future. Somewhere around RC1, we change all the symbols to be FBSD-7.0. There's no reason why we have to start at 1.0, and the disconnect between major release and ABI version seems artificial to me. Changing all the symbols near RC1 time would give all the ports builders a chance to shake out that process. Portmgr has stated that they want an RC1 from re@ about a month before the final release so they can do all the builds and work out whatever issues come up. It would give people a good point where packages are available to cope with the requirement to rebuild everything. It would also let us remove the compat hacks after the release in HEAD and before the release in RELENG_7. We can also keep the FBSD-1.x symbols around long enough for people to do the upgrades. I put "the release" in quotes because the release engineer gets to make the call when he wants to finally freeze things for the release. If that's RC1 great. If that's BETA1, great. If it is later, that's good too. We should allow him to make the call on the timing, since he has to coordinate the release with a lot of different people. Warner