From owner-cvs-src@FreeBSD.ORG Tue Aug 28 16:19:21 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04E9016A417; Tue, 28 Aug 2007 16:19:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 7583113C465; Tue, 28 Aug 2007 16:19:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8k2) with ESMTP id 205811547-1834499 for multiple; Tue, 28 Aug 2007 12:19:32 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l7SGJ4YU039259; Tue, 28 Aug 2007 12:19:06 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Yar Tikhiy Date: Tue, 28 Aug 2007 11:42:06 -0400 User-Agent: KMail/1.9.6 References: <200708270850.20904.jhb@freebsd.org> <20070828004842.GT21352@comp.chem.msu.su> In-Reply-To: <20070828004842.GT21352@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708281142.07941.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 28 Aug 2007 12:19:08 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4088/Tue Aug 28 07:51:32 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: src-committers@freebsd.org, peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, Daniel Eischen , cvs-src@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 16:19:21 -0000 On Monday 27 August 2007 08:48:42 pm Yar Tikhiy wrote: > On Mon, Aug 27, 2007 at 06:01:22PM -0400, Daniel Eischen wrote: > > On Mon, 27 Aug 2007, John Baldwin wrote: > > > > >On Monday 27 August 2007 05:38:08 pm Daniel Eischen wrote: > > >>>>it is today. > > >>> > > >>>So you want to just bump the version everytime a change happens in HEAD? > > >> > > >>No, I don't see how you get that from what I said... > > > > > >You originally objected to having fts compat symbols as 1.0 and wanted the > > >new > > >fts to be 1.0. Now you are saying that the new fts can be 1.1 and the old > > >ones (only used in old current) can remain 1.0. > > > > > >That is, now you are saying to do what Yar originally wanted to do before > > >you > > >objected. > > > > No, I still think they should be 1.0 or wait till after the > > release. I just made some assumption for the sake of giving > > an example. > > It's time to summarize previous discussion to prevent further > misunderstanding. :-) > > Let's recall the point all sides of this discussion seem to share: > symbol versions can give us ability to run binaries from a former > _release_ in a later _release_ without installing compat libraries. > Obviously, it will be available only after 7.0-RELEASE, the first > release with symbol versioning. _If this ability is the only goal_, > Daniel's position makes sense as it implies a minimal number of > distinct version labels and compatibility shims to support later. > I.e., we allow new version labels only after 7.0-RELEASE and we > allow at most one new version label for each successive major > release. That's how we make sure that every old version of a symbol > appeared in at least one former release, so that we don't have to > support old versions without release history. > > I say "version label" to emphasize the fact that the same version > strings of different symbols can correspond to totally unrelated > changes in them, which Daniel pointed out already. I.e., each > symbol can travel along the version axis independently. Moreover, > it's technically possible to have a separate version axis for as > little as each symbol, but it would be gross. > > Example: Assume we released 7.0-R with all symbols at FBSD_1.0. > Before the 8.0 release cycle starts, struct FTS and struct FILE > change, perhaps a few times each, thus affecting the fts(3) and > stdio(3) global symbols. At the very first change to a symbol or > their group, its 7.0-R variant is preserved at FBSD_1.0 and its > default version becomes FBSD_1.1. Later changes to the current > variant of that symbol don't affect its version. Consequently, > 8.0-R is released with the new fts(3) and stdio(3) symbols at > FBSD_1.1, their 7.0-R variants at FBSD_1.0, and the rest of symbols > still at FBSD_1.0 because they are unchanged. Let's note that > CURRENT users had to rebuild ports depending on fts(3) or stdio(3) > _each time_ an ABI component changed. > > Now let's see if we can help CURRENT users without putting too much > burden on our own back. That's where John's idea comes into play. > When a symbol changes in 8-CURRENT for the first time, it gets > promoted from FBSD_1.0 to, say, FBSD-current_1.0.1 while its 7.0-R > variant is preserved at FBSD_1.0. If the same symbol or group of > symbols has to change again and providing compatibility isn't too > expensive, there appear 2 compat versions for it, FBSD_1.0 and > FBSD-current_1.0.1, and 1 default version, FBSD_current-1.0.2. So > CURRENT users can keep older ports dependent on the intermediate > symbol(s). Just before the RELENG_8 branch, all default > FBSD-current_1.0.* symbol versions, if any, are flattened into a > single version, FBSD_1.1, while any compatibility shims at > FBSD-current_* are dropped. So we end up with exactly the same > 8.0-R library as in the previous example and from now on we have > to support only one old variant (7.0-R) of each symbol changed since > 7.0-R. The flattening of FBSD-current_* versions will be a flag > day for port users, but they'll have to rebuild affected ports only > once. Unfortunately, even those who built a dependent port a moment > before the flag day will have to rebuild it after the flag day. > Therefore we should recall how often multiple changes to the same > ABI component happened between a pair of successive major releases > to justify this approach. We can keep the last FBSD-current_1.0.* > symbols as aliases for FBSD_1.1 symbols in HEAD for a while, but > it means greater support burden and dependent ports still need > to be eventually rebuilt. Perhaps this is a way to go only in > case multiple changes to the same ABI component are really likely > to happen. > > As for committing new FBSD_1.1 versions of the fts(3) symbols right > now, there's nothing wrong with it technically, but it would set a > poor example of having old symbols around that have never been in > a release. Note that releases prior to 7.0 don't count here because > "fts_open" != "fts_open@FBSD_1.0". > > I hope I didn't misinterpret any ideas. :-) I think this is dead on, yes. Only comment I would add is that I think the "flag days" should be when a new RELENG_X is branched and that all the FBSD-current shims get tossed in the RELENG_X branch. The FBSD-current shims can be dropped from HEAD on a separate schedule, maybe where they get dropped after they've been around for 6 months or so. This does mean that stepping off -CURRENT onto RELENG_X requires a rebuild of your ports for any symbols that changed since RELENG_X-1, but I think that is tolerable. -- John Baldwin