cvs commit: src/lib/libc/locale utf8.c

[Erik Trulsson]

On Fri, Oct 26, 2007 at 11:44:33AM -0400, John Baldwin wrote:
> On Thursday 25 October 2007 07:04:08 pm Scott Long wrote:
> > Robert Watson wrote:
> > > On Thu, 25 Oct 2007, Andrey Chernov wrote:
> > > 
> > >> On Thu, Oct 25, 2007 at 12:05:40PM -0700, LI Xin wrote:
> > >>> Well, I think the problem is not exposing a new symbol by itself, but 
> > >>> __mb_sb_limit is being used in _ctype.h, in a form of __inline 
> > >>> functions. Therefore, the change will break new binaries running on 
> > >>> older systems.
> > >>
> > >> Yes. Only vice versa compatibility supported.
> > > 
> > > 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.  

That depends on exactly what you mean by 'forward compatibility'.

What I would expect (or at least desire) is that if I have program that
compiles and runs fine under 6.2, then if I recompile the program under 6.3
then the resulting binary should still work fine under 6.2.

If the program would use some feature that is available on 6.3 but not 6.2
then it would not have compiled or run under 6.2 in the first place and I
would certainly not expect it to do so just because I compile it under 6.3
I also do not expect that a program compiled with 7.x will work under 6.x.


I don't know how often this expectation has been broken in the past, but I
suspect it is not all that often.


> 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. :-/





-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013 at student.uu.se