Re: [RFC_v3] Handling Backwards Compatibility in PEAR

Hi Alan, The problem with a differing standard is that the installer can't automatically determine whether a newer API versoin exists to display an errror message if a user types: $ pear upgrade Foo Package Foo version 2.8 is available, use "pear install Foo_v2" It also might confuse some users: "what's the difference between db_ldap2 and db_ldap_v2 and db_ldap2_v2?" Of course, I'd like to know what everyone thinks - is the error message need worth the extra "_v" ? Or should we go with Alan's suggestion below? Greg Alan Knowles wrote:

db_ldap db_ldap2 When db_ldap2's version 2.0 API comes out, it will be db_ldap22 under the old RFC, db_ldap2_v2 under the new one. I toyed with using just _2, but db_ldap2_2 is a bit confusing - is that ldap 2.2? I didn't post these arguments publicly, but it is good to make them clear.

Good point, but I guess the reality is that is where balancing an minor issue against a bigger one comes into play.. - This situation is not very common.. .. same logic applies to NetIPv4_v1 .. - there are always going to be minor conflicts on a standard.. - but out of 200 packages so far, these kind of issues affect 4 packages at most.. In that case.. - perhaps we have a primary rule of Foo2 (and use v2 or r2 in the rare case of a conflict.. ) Regards Alan

Regards, Greg