Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Wed, 15 Dec 2004 15:21:25 -0800
From: Justin Erenkrantz <justin@erenkrantz.com>
To: Cliff Woolley <jwoolley@virginia.edu>
Cc: Brad Nicholes <BNICHOLES@novell.com>, dev@apr.apache.org
Subject: Re: Backport and release policy for APR and APR-UTIL...
Message-ID: <20041215232125.GR18584@scotch.ics.uci.edu>
Mail-Followup-To: Justin Erenkrantz <justin@erenkrantz.com>,
	Cliff Woolley <jwoolley@virginia.edu>,
	Brad Nicholes <BNICHOLES@novell.com>, dev@apr.apache.org
References: <s1c01067.056@sinclair.provo.novell.com>
 <Pine.GSO.4.58.0412151327470.11265@cobra.cs.Virginia.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.58.0412151327470.11265@cobra.cs.Virginia.EDU>
User-Agent: Mutt/1.5.6i

On Wed, Dec 15, 2004 at 01:29:02PM -0500, Cliff Woolley wrote:
> On Wed, 15 Dec 2004, Brad Nicholes wrote:
> 
> > release of APR 1.0.  Since then there has been a lot of activity in
> > TRUNK as compared to almost no activity in the 1.0.x branch.
> 
> After the 1.0.x branch was created at ApacheCon, Justin and Thom
> backported everything that they thought could be backported without
> breaking binary compatibility...

Correct.

I don't think we need to have as strict an RTC policy as httpd - but the only
issue is that any change that is backported can not break binary compatibility
at *all*.  Bumping the minor version (1.0->1.1) can add new functions, but it
can't change any existing functions at all.  And, bumping the major version
(i.e. 2.0) causes all bets to be off.  =)  -- justin