Date: Fri, 26 Oct 2007 16:59:07 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Scott Long <scottl@samsco.org>, src-committers@FreeBSD.org, d@delphij.net, Andrey Chernov <ache@nagual.pp.ru>, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/locale utf8.c Message-ID: <20071026165513.T99770@fledge.watson.org> In-Reply-To: <200710261144.34645.jhb@freebsd.org> References: <200710150951.l9F9pUm7026506@repoman.freebsd.org> <20071025233536.B99770@fledge.watson.org> <472120E8.90504@samsco.org> <200710261144.34645.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 Oct 2007, John Baldwin wrote: >>> I think the issue here is that the change occurred very quickly after the >>> branch, and when users wanted to 'change gears' back to RELENG_7 from HEAD >>> once it was created immediately ran into the problem. It seems like a >>> useful piece of post-branch advice to developers in the future will be, >>> "Please don't do things that make switching branches -- back or forward -- >>> for the first few weeks after the branch is created". In general, I don't >>> think we care about forward compatibility, but we are currently getting >>> lots of reports because this is one of those few times where a lot of >>> moving backward happens. >> >> We do care about forward compatibility within STABLE branches, as Ken and I >> have discussed in side threads. But yes, forward compat between major >> branches is merely desired; i.e. changes will happen, and hopefully not for >> gratuitous reasons. > > If we care about forward compatiblity then we can't add new features to > RELENG_X branches. For example, MFCing MSI to 6.x broke forward compat > since a 6.3 module might call the MSI methods thus can't be used on a 6.2 > kernel. AFAIK, we have _never_ promised anything wrt forward compat, only > backwards ABI compat. I can agree with Robert above that during a > transition time such as now it's really handy to be able to switch easily > between branches, but I didn't think it was ever a concern otherwise. If we > are going to change the policy for that then there's a whole bunch of crap I > need to go back out of 6.x to restore compat. :-/ It's certainly true that any time we add a facility and then components begin to depend on that facility, we won't be able to use those components on versions of FreeBSD before the facility was introduced, and we've generally been careful but not conservative about adding new facilities. Be it new kernel services that kernel modules depend on, new system calls that libc and friends grow a dependence on, new libraries that third party applications start to expect, etc. I think it is useful for binaries built on new versions of the same -STABLE branch to generally work on old ones *unless* they depend on an API or other facility not present on an older one, but I don't think we have a hard-and-fast rule so much as a "try not to gratuitously break things" expectation. Certainly over time we've become a lot more sensitive to issues of managing API and ABI change, and I think that's a good thing. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071026165513.T99770>