Re: [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

Hi! Lukas Smith wrote:

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.

Do you upgrade to a new major version on production server without first testing it on development one? Neither do I. If there are people who *do* this, new infrastructure will not really help here, they'll just add smore bugs changing the paths from Foo to Foo_v2.

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.

Why don't we just add "clear guidelines" and not break PEAR? See my point?

4) This may serve as a good excuse to not have tests, QA process and

other

necessary things.

I dont understand that argument.

As I said: "Well, this is a major version. It may or may not have BC breaks, but as it is installed to a different dir I don't really care" vs. "Well, this is a major version, but it passes all unit tests"

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. For PEAR installer to handle applications, *another* change is needed. It should be able to have *several* servers to download packages from.

And voila: you can do $ pear upgrade Horde The key word in THE ULTIMATE QUESTION is "mandatory".