Re: can I depend on stable PEAR classes to not change?

Culley Harrelson wrote:

Sounds like you need to either write all your code yourself, or pay someone else for it. Open source code evolves, and that's where a lot of its strength comes from. If you can't evolve with it, then *you* are making bad choices.

All code evolves not just open source code. But evolving code shouldn't mean unstable code. As a small business owner I can't afford to risk using a library unless I'm damn sure the maintainer isn't going to pull the API out from under me. This is partially me being conservative but is is also good common sense. I would expect corporate users of PEAR packages would be even more conservative than I am-- professional use requires rock solid stability. Code libraries should be flexible and extensible and my code shouldn't have to change because the library I use changed. A changing API is often either a sign of immaturity or rigidity of the underlying code-- it scares me and makes me question the library. I understand how things work-- sometimes an api has to change on order to evolve and everyone agrees that breaking BC is bad. I only wrote this response because I felt I needed to defend myself a little...

As a member of the core-QA team I wanted to respond on this :) The way PEAR now works, is that any BC break requires a new major version, and all major versions will now become a new package, i.e. XML_Tree will become XML_Tree2, which is as much a seperate package from XML_Tree as Text_Highlighter is. It means that you will go to pear.php.net/XML_Tree2 - and pear.php.net/XML_Tree will always (as much as anything is forever :) be available, it will just become stale (but stable :). This also means the class will be called XML_Tree2, and will reside in XML/Tree2.php. We (the QA team) are trying to get some automated tools together that will do an API check at upload time, whilst it won't be as good as human eyes it will provide a quick way to say it definately *has* changed (i.e. a file is missing, or a function is missing) I hope this helps to allay your fears. Of course, be sure to note the state of the package you are installing. We allow BC breaks in any release upto 1.0.0-stable (this includes RCs) however, we now suggest that developement starts at a '-dev' state, and from alpha onwards BC is discouraged, and heavily discouraged in RCs (really, only allowed to fix bugs not discovered before RC testing) - Then BC breaks are not allowed till a new major version is started. - Davey