Re: Breaking BC / Changing API / Deprecating

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 On Jul 19, 2005, at 10:30 AM, Arnaud Limbourg wrote:

Maybe I'm the only one that reads the CHANGELOG before updating? Also, as long as the package that depends on the BC broken package has been updated there shouldn't be any problems upgrading (as long as the depended upon package isn't used elsewhere). I guess I just don't see a huge need to "save the users" when these people would have had ample knowledge ahead of time, a CHANGELOG, etc. I'm not talking about rolling out a 2.0.0 release without first making it 2.0.0 alpha -> 2.0.1 beta -> 2.0.2 stable. They'd have plenty of time to fix their code.

Many don't. That is why it is important to iron out the API in alpha stage.

Are you kidding me? So when Payment_Process hits 2.0 I have to roll out Payment_Process2 and then when it hits 3.0 I have to roll out Payment_Process3? So what happens when 5 years from now I'm on version 5.0? Am I supposed to be supporting this package indefinitely? And, if not, then can I move Payment_Process5 back to Payment_Process (as it's not being actively developed or supported I should be able to totally break it).

Not at all, you can hit 2.0 as long as the API is the same. You can change it entirely as long as you provide the previous API (you can make it use the new one). Mark the previous API deprecated and you're set. Think about shared hosts trying to maitain one system-wide pear install (and I know many have tried and gave up), if a new release means BC break you are making their life a nightmare. Arnaud.