httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [ANNOUNCE] libapreq2-2.01_03-dev released
Date Wed, 12 Nov 2003 01:07:00 GMT
Joe Schaefer wrote:
> Stas Bekman <> writes:
>>Joe Schaefer wrote:
>>>    - This is a developer release, indicated by the "-dev" suffix
>>>      on the version string.  We believe the core interfaces to be stable,
>>>      but some portions of the API may still need significant modification.
>>>      Thus, binary/source compatibility may be broken from one developer
>>>release to the next. In particular the version numbering rules specified
>>>      at
>>Joe, are you sure you are not artificially building acceptance walls?
>>You are talking about C API in the post to the mod_perl list. Most
>>people won't even try it, because of that.
> "Most people" shouldn't try it- developers should.  It's their feedback
> that determines what we most need to change.  At this point, perl users 
> need to be looking to *the test suite* for the stable components of the
> API, not *the documentation*.  Until that situation changes, I see no
> harm in scaring off the faint of heart.

Those developers are "most people", they won't try it in their code if you say 
that the perl API is not stable. I guess I'm talking mostly about those 
developers who wait in anxiety for the Apache::Request 2.0 release so they can 
move to mod_perl 2.0. I could be wrong.

>>Or does it really true the perl may still need significant
> Absolutely.  We need to really flesh out the perl glue in CGI 
> before we can claim stability, just like we needed to do it for 
> the C API.

OK, thanks for the clarification, Joe.

>>I thought it's going to stay pretty close to the apreq1 API.
> "Pretty close" is what the tests are there for.


Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message