Re: BC breakage results

Zitat von Alexey Borzov <borz_off@cs.msu.su>: > Hi! > > Greg Beaver wrote: > > We've reached what seems to be a typical position: lots of stuff has > > been said, and no one is in favor of anything to solve the problems, so > > business continues as usual :). > > > > Unresolved questions that need attention: > > > > 1) What should be done about minor BC breakage? > > Minor BC breakage should be clearly communicated and resolved between > package > developers and clearly stated in release notes for the users. That doesn't help at all. It's not hard to notice that the time spent by the several PEAR developers or even PHP user differ drastically. Take the PEAR developer Doe who's working night and day on his packages and release a new (breaking) version every month. A dozen other developers depend on each of his 5 packages and each of these developers has 500 users of their software. You really want these 30,000 people to keep up with this PEAR devloper's development speed just to make sure that nothing breaks their software? Cool idea. > For the record: I don't think that we should require x.0 releases for > each minor > BC breakage. Or else some PEAR packages risk reaching 20.0 quite soon. And? What's wrong with that? And btw, if you design you package well you don't have to break bc that often, not mentioning that you have the whole beta lifetime to mature your api, you can always add new methods without bc breakage and there several ways like compatibility layers that avoid bc breakage even if you change your API. > > 2) How much of an API change would be necessary to do a Package2 > release? > > That should be decided by package maintainer. My point of view is that if > this > is feasible to have 2 versions of package and use them *both* at the same > time, > then go for Foo2. > I'd also say "API change that cannot be handled by Search/Replace". No, see above. > > I am starting to believe that PEAR wants an impossibility: you can't > > have BOTH BC and automatic upgrades without some kind of structure. > > The question is: won't this structure add more problems than it is trying > to > solve? I haven't seen much complaints about BC breakage from PEAR users, > only > from few PEAR developers... Because the PEAR developers are the middle men. And because most of the PEAR users are actually developers themselves. Do you have any idea how much user complaints/frustration we have or had to handle on the Horde mailing lists because of disappeared HCEMD5.php, Select.php or Span.php files or missing DB::isWarning() methods? Just for the records, I am +1 for having new major versions for each api break and introducing the Foo2 package style. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft