Date: Tue, 28 Aug 2007 04:48:42 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Daniel Eischen <deischen@freebsd.org> Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <20070828004842.GT21352@comp.chem.msu.su> In-Reply-To: <Pine.GSO.4.64.0708271757570.28508@sea.ntplx.net> References: <200708270850.20904.jhb@freebsd.org> <200708271715.21462.jhb@freebsd.org> <Pine.GSO.4.64.0708271719510.28508@sea.ntplx.net> <200708271757.01674.jhb@freebsd.org> <Pine.GSO.4.64.0708271757570.28508@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. :-) -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070828004842.GT21352>