RE: [PEAR-DEV] BC breakage results

> -----Original Message----- > From: Alexey Borzov [mailto:borz_off@cs.msu.su] > Sent: Friday, September 19, 2003 2:13 AM > To: Greg Beaver > Cc: pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] BC breakage results > > > > > > 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. > 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. I disagree breakage is breakage, not matter how minor. Once a package is released as stable, THE API SHOULD NOT CHANGE EVER EVER EVER EVER EVER EVER PERIOD. That is basic rule number in in revision control. Only bugfixes and security updates should be made to a stable package. If the API is changing enough to get to version 20 quickly, then I question whether that package should have been marked stable in the first place. OK, back to the real world, maybe minor BC breakage within minor releases, but it needs to be because of a "bugfix", as in one that causes a problem, not just because the developer decided to change the name of a function. Marking a method as private that was public is not a bugfix. That is a, man I really shouldn't have done that. It should only be marked depreciated with a comment in a minor release. > > > 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". Guidlines have to be set or Pear will end up bakc where it is with the "package maintainer is responsible for deciding the appropriate amount of documentation". > > > 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... Being from outside of the project I can tell you that the disorganization, perceived or real, in the past has a major roadblock for people contributing. Structure for th sake of structure is bad, but structure for the sake of bringing organization to the beast is good. I think the foo, foo2, foo3, foo4 idea is a good one. If BC breakage is more than something done to fix a problem, then the maintainer of a dependant package is under no demand to upgrade the package to the new API. Some packagers may do it quick, some may take a while. If the API is changed, then it may not be possible to maintain backward compatibility in a dependant app. What happens when one maintainer upgrades their package, but it takes 2 or 3 weeks or even months for another package to be upgraded. It may take majoe restructuring in one, and minor changes in another. What happens when I want to take advantage of some new functionality in a class where the API has been upgraded, but need to maintain BC in other areas of code. The only answer that I can see is to have major revs in separate directories, and change the object name and main file name accordingly. You can always offer a compatability class. If the BC is minor enough in your app to not need to do major rewrites, simple wrap the newer version in an object with the older name. Simple... > > > The only solution that can solve the problem without the changes I've > > proposed is to explicitly state that any packages with > dependencies must > > depend on the latest version of the package, or be considered to be > > outdated and no longer viable. So, which is it folks? Solve the > > problem by allowing older versions of packages to co-exist with their > > newer versions, or simply keep things as they are, and change the way > > the "ge" relation works? > > I'd go for the third option: don't touch anything. > If you don't want to check whether your package will be > compatible with latest > version of dependency, add explicit version/version range to > <dep> tag. This > will also communicate something important to the package's users, > which will not > be so obvious in "automatic" resolution. > Agreed > > Documentation and automated testing will solve most of the problems. > Of course, it is more fun to write RFCs than docs and tests. ;P The problem is, from past experience the Docs and Tests will not get done without the RFC... Thanks, Rob