From owner-freebsd-hackers  Sun Jul  6 11:56:30 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id LAA01928
          for hackers-outgoing; Sun, 6 Jul 1997 11:56:30 -0700 (PDT)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA01920
          for <freebsd-hackers@freebsd.org>; Sun, 6 Jul 1997 11:56:26 -0700 (PDT)
Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1)
	id 0wkwPN-0003cO-00; Sun, 6 Jul 1997 11:51:41 -0700
Date: Sun, 6 Jul 1997 11:51:40 -0700 (PDT)
From: Tom Samplonius <tom@sdf.com>
To: Kent Boortz <kent@erlang.ericsson.se>
cc: freebsd-hackers@freebsd.org
Subject: Re: Application os version compatibility?
In-Reply-To: <199707061132.NAA29134@townsend.ericsson.se>
Message-ID: <Pine.BSF.3.95q.970706114608.13881A-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Sun, 6 Jul 1997, Kent Boortz wrote:

> Thank you Tom, it is more clear to me know but I'm still a bit
> confused.
> 
> >   The libc version is ONLY changed if the interface changes.  If the
> > interface changes, some applications will not work.  Hence, the version
> > number change.
> 
> Do you talk about "system calls" like read/write? Or the interface
> from the library to the user, like fread/fwrite? 

  Only about libc, as that what the original message was about.

> >   Huh?  Statically linked applications ALWAYS work.
> 
> Could it be the case that a new system call is added from FreeBSD
> X.X.1 to X.X.2 and for example a new libc.a implement fopen() with
> this new call?  Then running even statically linked applications
> compiled in X.X.2 running on X.X.1 will break, right? 
> 
> Do the behaviour of system calls *ever* change change in an 
> incompatible way?

  I don't believe this has ever happened.  A new syscall would be created
in that case.  New syscalls have been added, but the behaviour of existing
syscalls are rarely changed, and then generally to fix bugs.

..
> There will be other libraries than 'libc' in this application.
> What I'm after is that if I compile and release a 2.2.2 version
> and an unreleased 2.2.3 shows up that "there is a good chance" it will
> work. No guarantee of cause, I may have to do a new release or
> give instruction how to use a compatibility package or something.

  This should almost be guarrenteed.  When there is a post 2.2.2 release,
it should maintain full compatibility.  Only bug fixes and minor feature
improvements are going into 2.2.2.  Big API changes are definitely NOT the
thing that would go into the 2.2 branch.

Tom