From dev-return-7716-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Aug 14 17:45:14 2002 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 45527 invoked by uid 500); 14 Aug 2002 17:45:14 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 45516 invoked from network); 14 Aug 2002 17:45:13 -0000 Date: Wed, 14 Aug 2002 10:45:17 -0700 From: Aaron Bannert To: APR Development List Subject: Re: Versioning before time please Message-ID: <20020814174517.GC9080@clove.org> Mail-Followup-To: Aaron Bannert , APR Development List References: <200208131910.PAA25758@devsys.jaguNET.com> <20020813212027.GG6479@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020813212027.GG6479@apache.org> User-Agent: Mutt/1.4i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, Aug 13, 2002 at 02:20:27PM -0700, Justin Erenkrantz wrote: > Which is exactly why we should table the time discussion until > we have a versioning system *enforced*. > > Aaron has explicitly veto'd any changes to apr_time_t that cause > broken binary compatibility (i.e. changing the meaning of > apr_time_t but not the API). Whether I agree or disagree doesn't > matter. It's a valid veto and I've spent too much time arguing > (and then agreeing) with Aaron about this. > > The one thing we agreed upon was that if we have the versioning in > place, then we can do whatever we want to apr_time_t since the app > has a way of knowing that binary compatibility isn't met. > > So, let's get versioning enforced, and then we have a mechanism for > breaking (or enhancing) apr_time_t. And, at this point, I don't > care much what happens to apr_time_t. My only requirement is that > if it changes and we don't bust the API, then we have to bump the > version. -- justin Thank you and well said: Huge +1 -aaron