Craig, thank you for submitting this patch. At the moment we are trying to maintain source and some binary compatibility between revisions. When we've hit the big 1.0, all have agreed that the old symbols will go *poof* and we will be left with a clean API.
-#define FNM_NOMATCH 1 /**< Match failed. */ +#define APR_FNM_NOMATCH 1 /**< Match failed. */ + +#define FNM_NOMATCH APR_FNM_NOMATCH /**< @deprecated */ is what we are looking for to keep code that compiled in 0.9.2-dev building in 0.9.3-dev and onwards, until the magic APR 1.0.0 arrives :-) To your other question; will likely apply your patch, deprecating your old symbols; finish the other_child work for win32/unix work-alike behavior, and then tag a 0_9_2_RC1 candidate for everyone's review. This was to have happened this afternoon, it now looks more like Saturday evening. Bill At 08:20 PM 2/13/2003, Craig Rodrigues wrote: >On Wed, Feb 12, 2003 at 11:45:37PM -0500, Rodent of Unusual Size wrote: >> Some headers with issues: >> apr_fnmatch.h (FNM_foo) >> apr_general.h (MAXIMUM_WAIT_OBJECTS) >> apr_md5.h (MD5_DIGESTSIZE) >> apr_network_io.h (MAX_SECONDS_TO_LINGER) > > >Hi, > >I already submitted this patch last week to address these issues >mentioned in the STATUS messages that are posted on this >mailing list. > >Can someone with commit access to apr look at these patches, >please? > >Also, what are the issues that are holding up an apr-0.9.2 release? > >I am the FreeBSD port maintainer of apr and subversion, and the >lack of a apr-0.9.2 release is preventing updates to the subversion >port, which a lot of FreeBSD users have been asking me for. > >Thanks. >-- >Craig Rodrigues >http://home.attbi.com/~rodrigc >[EMAIL PROTECTED]
