apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: RTC on 0.9.x? was Re: svn commit: r161087 - in apr/apr-util/branches/0.9.x: CHANGES include/apr_reslist.h misc/apr_reslist.c
Date Wed, 07 Sep 2005 20:07:03 GMT
Justin Erenkrantz wrote:
> --On Tuesday, April 12, 2005 4:28 PM -0400 Cliff Woolley 
> <jwoolley@virginia.edu> wrote:
>> I was also under the impression that all branches of APR were CTR.
>> However, I agree that discussion on API changes would be good, even in a
>> CTR system.  That has always been the basic idea with CTR -- you can
>> commit without prior review, but it is understood that anything major 
>> will
>> be discussed ahead of time.
> +1.  -- justin

I don't agree with a 'hard and fast' rule, that's broken httpd horridly.

But note we were going to bump 'version minor' every time we introduced
new functions - at least that's what Greg's original versioning doc had
suggested.  "Changes" require a version major bump (e.g. it doesn't
match a previous, released API, causing ABI breakage.)

AFA APR[-FOO] 0.9, all bets are off, since we had no rules back then.

So, API changes are always good, they either bump minor (new feature)
or bump major (which should be managed by the whole project so we can
get in and deprecate dead functions).

But we gotta work as a team - and more rules don't help, cooperation
does.  This is why I brought up the apr_dso and apr_app functions to
determine full paths to an arbitrary loaded library/application's path.
Better to warn all, get as much feedback as possible before doing 'new


View raw message