Re: [RFC2] Handling Backwards Compatibility in PEAR

On 20 Sep 2003 at 11:46, Greg Beaver wrote: > Stefan Neufeind wrote: > > >Well, if we (Alexey and me) mis-understood each other *that* much > >then Greg you're right ... and my apologize go to Alexey for mis- > >understanding him. The way I understood Alexey was that "a complete > >API break" or "complete rewrite" would require a new major version. > >But "minor breaks" could be solved also inside the same major > >version. And that's what lead me to the point of thinking "hmm, > >renaming a function is only a minor break so he didn't want to bump > >the major version so users might get into problems". > > > I didn't read this in what Alexey wrote, I just figured Alexey was > defining version numbering. The problem of minor BC breaks is the > reason why it needs to be possible to do this versioning scheme: > > Foo 1.0.0 > Foo 1.0.1 bugfixes > Foo 1.1.0 feature additions > Foo 2.0.0 minor BC breakage - the package is essentially the same, > users must do text search-and-replace for a few methods Foo 2.1.0 etc. > Foo3 3.0.0 MAJOR BC breakage - whole API is reworked to give major new > features not possible with Foo 2.x, give users whose apps only need > the functionality of Foo 2.x no need to rewrite their apps, and allow > newer code to co-exist if necessary with older code until the old code > is rewritten in the future. Yes, and this minor brake in 2.0.0 is the thing I can't get myself friendly with. Or do you mean "deprecated" functions? That would be okay. But if 1.x and 2.x are not API-compatible we would end in the same problem wherefor we introduced the whole Foo / Foo2-thing. I'm against API-breaks in the same package (here: all inside Foo). Stefan