3) Foo_Bar2 will be a different class thus it does not break BC.
Oh please! If I have a major application that relies on Foo_Bar, but want to use Foo_Bar2 because it has some new features I like I have to change *every* require and call to Foo_Bar to Foo_Bar2. If that's not a BC I don't know what is.
--Joe
4) http://pear.php.net/pepr/pepr-proposal-show.php?id=65
Arnaud.
Joe Stump wrote:
OK, then someone answer a few things the RFC doesn't address.
1.) If a package has a 0.2 stable release, but no stable release over 1.0 can I break BC and make API changes? According to the RFC I can break BC within 0.*.* series and, since the package's 1.0.1beta was never stable this rule should still apply (btw, I'm talking about Net_Curl). As no stable 1.0.0 release was ever made should I not be able to break BC and/or change the API? If I don't break the API, but merely deprecate the stuff and it still behaves as normal then there shouldn't be any issues.
2.) If a package goes from Foo_Bar to Foo_Bar2 how long must Foo_Bar be maintained?
3.) Are classes in Foo_Bar2 still just Foo_Bar or are they Foo_Bar2? If they are Foo_Bar2 then how does this not break BC?
4.) Where is the document mentioned in the RFC referred to as "major package naming document".
--Joe