Mailing-List: contact cvs-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
Content-Type: text/plain;
  charset="iso-8859-1"
From: Ryan Bloom <rbb@covalent.net>
Reply-To: rbb@covalent.net
Organization: Covalent Technologies
To: dev@apr.apache.org, gstein@apache.org, apr-cvs@apache.org
Subject: Re: cvs commit: apr/test testvsn.c .cvsignore Makefile.in
Date: Sun, 11 Nov 2001 09:14:42 -0800
References: <20011111072357.93819.qmail@icarus.apache.org>
In-Reply-To: <20011111072357.93819.qmail@icarus.apache.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20011111171443.32C8846DFD@koj.rkbloom.net>

On Saturday 10 November 2001 11:23 pm, gstein@apache.org wrote:

>     ### we have not defined source/binary compatibility guidelines yet and
>     ### how those map against these (release) version numbers. a strawman
>     ### would be the following text:

We should have this discussion now.

>     APR is binary-compatible (an app compiled against one version does not
>     need to be recompiled to work against another version) for the same
>     MAJOR and MINOR versions.
>
>     APR is source-compatible (an app needs to be recompiled, but will work
>     the same) for the same MAJOR version.
>
>     If the MAJOR version changes, then an application may need source
> changes.

This is a library, backwards compatibility is a must.  If we break backwards
compat after we release, we will have broken a lot of users.  -0.9 for ever
allowing backwards compat to be broken.  If the MAJOR number is increasing,
then a program should never need to be re-compiled, let alone source changes.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------