Date: Mon, 27 Aug 2007 15:39:48 -0400 From: John Baldwin <jhb@freebsd.org> To: Daniel Eischen <deischen@freebsd.org> Cc: src-committers@freebsd.org, peterjeremy@optushome.com.au, yar@comp.chem.msu.su, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, kensmith@cse.buffalo.edu, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <200708271539.49455.jhb@freebsd.org> In-Reply-To: <Pine.GSO.4.64.0708271419060.28508@sea.ntplx.net> References: <200708270932.31208.jhb@freebsd.org> <20070827.121033.1102529566.imp@bsdimp.com> <Pine.GSO.4.64.0708271419060.28508@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 27 August 2007 02:39:26 pm Daniel Eischen wrote: > > 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. > > You only need to bump symbol versions once when the first ABI change > occurs, and after that, only again when an ABI from the second > version changes. There's no need to bump for the sake of bumping, > and it doesn't really buy us anything except confusing us with more > version namespaces. > > I think we need to separate the version namespace from releases, > with the caveat we only care about the symbols that we export from > a release, not intermediate steps. If we want a way to list the > symbols from a release, we can do that with other tools or autogenerate > a file that is committed everytime we add symbols to a version. > Having versions tied to releases will just make it harder for us > to maintain, especially when you think about maintaining 2 or 3 > branches at once (RELENG_7, RELENG_8, and RELENG_9). I agree, but I see fbsd-current for non-released symbols (changes in HEAD that aren't in a release yet) as a compromise that let's the "real" symbols follow this path. > > 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. > > I have to disagree pretty heavily here. Symbols shouldn't be tied > to a release. Especially when you start to backport changes to > previous branches. When you backport changes to previous branches, > now you are going to have FBSD_8.0 symbols in FBSD_7.0. Thinking > about the symbol namespace this way isn't what you want, and if > you think off in to the future, you'll see that you'll start > having the same set of functions (with same ABI) appearing in > multiple versions. Ok, I can live with tossing the 7.0 renumber. However, what about the larger picture (ignoring specific numbers) of allowing for the future by using a separate namespace (fbsd-current) for ABI changes that happen in HEAD and only promoting those symbols into the "real" fbsd namespace when a RELENG_X branch is branched? This preserves the desired behavior of the "real" symbols and allows us to not keep a lot of compat gunk around for versions of symbols that were never released (at least not in the releases) while still giving other folks a slightly less rough-edged -current when navigating the various ABI breakages. > It is much easier to change the ABI version once when the first > ABI change occurs, and only ever change it again when an ABI > from the current (ABI) version changes. The key thing I think is ease-of-use for developer vs ease-of-use for for users on the branch. AFAIK, ELF major numbers for shared libs didn't allow us a way to provide a private version space for unreleased ABI changes in HEAD, so we just lived with the pain of a single bump per HEAD cycle in the past. Now that there is a more fine-grained tool that does allow for things like a private version space for HEAD, there are folks who want to take advantage of it to help out with the ease-of-use for running -current on systems. My primary concern is that we find a way to minimize the amount of compat shims in the releases to the bare minimum needed to reduce future maintenance, etc. costs. I think having a private namespace for unreleased symbols in HEAD can give us that (in RELENG_X branches we only have "released" symbols, and in HEAD we phase out private compat symbols on whatever schedule seems suitable) while still letting folks use symbol versioning to make HEAD a little less rough-edged. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708271539.49455.jhb>