Return-Path: 
 <dev-return-9581-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 51810 invoked by uid 500); 31 Mar 2003 01:42:29 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 51797 invoked from network); 31 Mar 2003 01:42:29 -0000
Date: Sun, 30 Mar 2003 17:42:38 -0800
From: Justin Erenkrantz <justin@erenkrantz.com>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
cc: dev@apr.apache.org
Subject: Re: Versioning policy was Re: [PATCH] fix apr-config with  symlinks
Message-ID: <2147483647.1049046158@[10.0.1.21]>
In-Reply-To: <5.2.0.9.2.20030330193052.02770a18@pop3.rowe-clan.net>
References: <5.2.0.9.2.20030328123530.018067c8@pop3.rowe-clan.net>
 <5.2.0.9.2.20030328123530.018067c8@pop3.rowe-clan.net>
 <5.2.0.9.2.20030330193052.02770a18@pop3.rowe-clan.net>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=-2.5 required=5.0
	tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES
	version=2.50-cvs
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

--On Sunday, March 30, 2003 7:31 PM -0600 "William A. Rowe, Jr." 
<wrowe@rowe-clan.net> wrote:

> No... I like the every-other thought.  I'd go odds-devel/evens-release.

And, what exactly is a odds-devel release?

To clarify, what has been suggested for the odds/even policy is this:

1.0.0: <initial>
1.0.1: <devel>
1.0.2: <release>
1.0.3: <devel>
1.0.4: <release>

No statement on how compatibility is achieved in this model.

Or, do you mean something closer to httpd:

1.0.0: <initial>
1.0.1: <binary compatible>
1.1.0: <devel - not compatible with 1.0>
1.1.1: <binary compatible with 1.1.0>
1.2.0: <release - not compatible with 1.1>
1.2.1: <binary compatible with 1.2.0>
...

The documented versioning policy we have says:

1.0.0: <initial>
1.0.1: <binary compatible with 1.0.0>
1.0.2: <binary compatible with 1.0.0>
1.1.0: <source compatible, but not binary compatible>
2.0.0: <not compatible at all with prior releases>

For a library, I like the last system by far.  -- justin