Re: BC breakage results

Zitat von Greg Beaver <greg@chiaraquartet.net>: > 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. Glad to hear that. If BC breaks are in the range that Rob (I think it was him) proposed, e.g. to fix critical bugs or to fix an earlier accidental BC break, I'm fine with that. And I don't even think that anyone needs to be informed about that before the release. > 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. That was me (among others). So, yes, I agree. :-). And as you say, extending the API is always a viable solution. > 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. I still think that this would lead to confusion. You can bump your minor versions up to 1.100 or more for package Foo. 2.x should be reserved (and mandatory) for package Foo2. > 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? Yes. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft