Re: BC breakage results

Jan Schneider wrote:

Zitat von Greg Beaver <greg@chiaraquartet.net>:

How's this for a solution: Add a requirement to the coding standards page that says if any other PEAR packages depend on your package, and you are going to make a minor change, you must notify the maintainer of that package so that they can do a release that is compatible with your new package's version, or one that requires an earlier version. A two week waiting period should be allowed for people to respond, and then if nothing is heard back, it's their problem and not yours if the minor break kills their package.

I feel like fighting against wind mills. You just *don't know* who depends on your package. The world is bigger than the PEAR universe. And it's not acceptable that developers or users have to change/update their programs/packages because one package they depend on changes its api (and I think we're still talking about the api here) in version that should only contain bug fixes or enhancements. And your last sentence is simply arrogant.

I'm very sure you misinterpreted what I was saying :). If I am working on package X, and developer dip has decided to take a 2 year vacation from maintaining package Z which depends on package X, I should probably be allowed to make changes to package X that fix bugs by breaking BC for 1% of users but fix critical bugs for 99% of the rest of the users and break something in package Z without waiting 2 years to hear back from developer dip. I don't intend any arrogance at all, and I can understand that from your perspective thinking of Span.php and such, I seem to be saying "F*** those peons who depend on my package" but that's not at all what I mean - I trust my actions with the packages I maintain speak louder than these words. Call it what you'd like, but I have done nothing but try to solve the problem, rather than complain about it. Of course, what I wrote above was based on the opinion that perhaps a little BC break is OK now and then. The more I think about my own code, if I break BC, I always increment version number even for minor BC breaks - most of the time I simply add another method which can be used for the new feature. I'm sure that a well-designed API doesn't NEED to break BC often, as someone pointed out. This makes me in favor of BC breaks can only be in a (stable) major version increase, no matter how minute. BC breaks in drivers can be solved by the subpackage solution, then the whole package doesn't need a major new release. I also feel strongly that if a package Foo decides to go to Foo2, ALL feature development in Foo should stop, so that a major version increase is no longer an option - Foo2 will eventually replace the outdated Foo package. If there is any chance of Foo going to 2.0, Foo2 is not Foo2, it is a separate package that does the same thing as Foo. Perhaps this is in fact the litmus test of whether a package should go to Packagex where x is a major version number. If the package Foo is fully mature and has reached its limits and the only fixes made will be bugfixes, then all new features must be added to Foo2, and it should be split off. Does that sound reasonable? Greg