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