cvs commit: src/sys/compat/linux linux_socket.c

[Paul Richards]

On Wed, Mar 09, 2005 at 11:13:39PM +0200, Maxim Sobolev wrote:
> M. Warner Losh wrote:
> >In message: <422F087F.9030906 at portaone.com>
> >            Maxim Sobolev <sobomax at portaone.com> writes:
> >: and need this tool to upgrade otherwise perfectly working system(s).
> >
> >As a veteran of ABI wars, I think that you have an unrealistic
> >expectations about what can be done.  While an interesting goal, too
> >many of the developers are hard wired to not even think about such
> >considerations to make it successful.  We have a hard enough time
> >making backward compatibility work, there's no hope for 'forward'
> >compatability.
> 
> As a junior of ABI wars I think I have a realistic expectation about 
> what can be done. Yes, many developers don't care about `backward' 
> compatibility, let alone `forward' compatibility, but in fact both are 
> really necessary in we want to position FreeBSD as a sound design.

>From a commercial standpoint, forwards compatibility is I think
actually more important. When you release a commercial product
you're actually more concerned about it working on already existing
systems.

Imagine something like Photoshop being written on the most recent
version of Mac OS X and finding that compatibility only worked
forward.  That would mean that most users out there would have to
upgrade their OS in order to use the most recent version of Photoshop!
What's most important commercially is that you can use the most up
to date development environment to target the largest possible
installed user base. It matters a lot less if you have to support
patches for newer systems since that's a much smaller user base to
support and the onward development of your own product tends to
keep pace with future platform changes.

A "stable" ABI means it doesn't change, not that it changes in a
backwards compatible manner. We should be able to enhance future
versions of a branch without creating these ABI incompatibilities
by supporting the existing interfaces until a future major release
removes them.

Better yet, lets stop "developing" our stable branches and focus
on stabilising them and getter more rapid development done in our
-current branch. There was a rash of MFCs for the next stable release
which were nothing more than a feature push and were of dubious
value in helping stability.

-- 
Paul Richards