RE: [PEAR-DEV] [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

> From: Alexey Borzov [mailto:borz_off@cs.msu.su] > Sent: Thursday, September 25, 2003 2:52 PM > Greg Beaver wrote: > > [RFC3] Handling Backwards Compatibility in PEAR > > Sept. 24, 2003 > > Greg Beaver , Lukas Smith > > Alexey Borzov, contributor [Announcing API Changes] > > While I do agree that some solution for BC handling is necessary I think > that > the proposed solution has HUGE potential problems. > 1) The proposed handling for mostly-compatible major versions and complete > API > changes is the same: this adds to confusion. Well this is a question of perception. I think it is unrealistic to assume that a package that has seen a major rewrite does not break BC. It is simply the norm. This may not be on the API level, but as I pointed out in hidden new bugs, unknown bugs being fixed, patch incompatibility, performance differences etc. Therefore imho it does not add to confusion but it makes it more clear that you are actually playing with a different beast now, eventhough the API might have not changed. Essentially what I am saying is that breaking BC is not just about having made changes to the API. There is much more to it. > 2) The BIGGEST problem: after upgrading to a new major version of the > package > I'll have to edit my application even if it is *completely* compatible. > This can > lead to: > 2a) Confusion: release notes state that Foo version 3.0 has major > performance > improvements, why don't I notice anything after upgading to it?.. > 2b) Bit rot: now authors of dependent packages should at least follow > the > development of their dependencies. Wonderful things can happen when they > know > that they can always rely on an old and buggy version... > 2c) It will be *necessary* to depend on a *specific* package version > after > implementing this RFC. It is *possible*, but not *necessary* now. 2a) and 2b) I don't see as an issue. 2c) is an issue. However since major version changes imply a drastic change in behaviour I don't see this so much as an issue. Today we never really had clear guidelines. So I am hoping that as a result of these guide lines API changes will be reduced because developer are now more aware of what this actually means for PEAR and its users. > 3) This may add complications for package authors, which leads to less > packages > and slower development Major version updates should not happen often. > 4) This may serve as a good excuse to not have tests, QA process and other > necessary things. I dont understand that argument. > THE ULTIMATE QUESTION THAT SHOULD BE ANSWERED BEFORE IMPLEMENTING THIS > 1) There are people who may need to run several mostly API-compatible > versions > of a package at once. What exactly prevents them from doing the custom > versions > themselves, when needed? Why should this be mandatory and implemented at > the > PEAR framework level? Indeed. I can maintain forks of every package myself. I don't use the pear installer for my applications atm anyways. But I was sort of hoping that the pear installer would soon enable me to also handle applications. Regards, Lukas