3.) True, it does not, but the majority of the code written in PEAR
fullows humpBack, as did many of the variables and functions in
Net_Curl. This lead to inconsistency within the package and went
against common practices in PEAR (even if it's no CS per se).
Considering how broken the previous Net_Curl package is/was and the
fact that only one package relies on this I think it's fine to break
BC in this case.
Version naming policy[1] states:
"BC may only be broken in releases that have a version number of "x.0.0" with
a state lower than stable or that have a version number below "1.0.0". As a
converse only releases that break BC or that have a version number of "1.0.0"
may increase the major version number compared to the previous release."
The last stable release was 0.2. The "latest" release (over a year old) is beta and, as far as the package history is concerned, the package never reached "x.0.0". I plan on this version being 1.0.0 stable (finally) of Net_Curl.
4.) Yup. Not my code, but it was valid code. Also, I believe 3xx
codes are for redirections, which is a non-issue for Net_Curl since
it is set up to follow location, thus the *final* code should either
be a 2xx or some error code (4xx or 5xx). I'll update the code just
to be safe as I find your suggestion a cleaner implementation.
Actually, in a later patch you'll note that I *do* use the substr(),
but don't check for 3xx.
So what happens on the first request where you get the 30x? Does it return a
PEAR_Error? What if follow_location isn't set?
I've implemented your fix so this is a moot point now. Thanks for catching this.
I've implemented all of Ian's fixes and remarks (the ones that applied) and updated my list of patches:
http://zebulon.miester.org/~jstump/pear/Net_Curl/
--Joe