Re: [RFC_v3] Handling Backwards Compatibility in PEAR

On 25 Sep 2003 at 9:58, 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.. But if you write a DB-layer for DB2 (mind the "2" at the end; okay, it would not be published as a separate package - but ...) or anything else the problem might arise again and again. Sure it's not common, but it occurs from time to time. > In that case.. - perhaps we have a primary rule of Foo2 (and use v2 or > r2 in the rare case of a conflict.. ) I'm against naming all Foo2 and the rare cases Foo99_v2 or such. I guess this would also lead to problems with pearweb etc. which should be able to parse the package-names. Okay, we need to make sure that noone uses _v2 as part of his package-name ... but I guess we can arrange that :-) So always using one naming-convention is IMHO the best solution. Therefor I prefer Foo_v2 over Foo2. Stefan