Re: Breaking BC / Changing API / Deprecating
| From: | Arnaud Limbourg | Date: | Tue, 19 Jul 2005 18:42:13 +0000 |
| Subject: | Re: Breaking BC / Changing API / Deprecating | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-38739@lists.php.net to get a copy of this message | ||
1) That is a difficult question raised for packages which have seen the light of day before the RFC.
2) It is up to the maintainer. The maintainer can call on the community for somebody to maitain it if resources are scarce.
3) Foo_Bar2 will be a different class thus it does not break BC.
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