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

Hi! Tobias Schlitt wrote:

I disagree with that. After most 'basic' classes exist in PEAR people start more and more complex classes and packages. Because of that more and more dependencies exist between PEAR packages. This will become a heavy issue for every PEAR developer, who uses other packages in his own.

I think depending on a package is a matter of trust: if you don't trust me, why should you depend on my package?

Apart from that, PEAR provides components for usage in applications (for what else?) and for that BC breaks have to be avoided.

This is addressed in the ULTIMATE QUESTION.

1) The proposed handling for mostly-compatible major versions and complete API changes is the same: this adds to confusion.

Sorry, I do not understand this point.

What is Foo_v3: a package with completely new API or Foo with major feature additions. You can't know without reading the changelog, just as it is now.

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

Right. But maybe we have to decide, whats better? Change the complete application, when a BC break occurs within a major version or, when it changes. Every application developer can decide himself, if he'd like to use the new version (then he has to accept the changes) or the old one.

Just as it is now: you don't want new features, you don't upgrade. But you don't need to spend time changing the files if you *do* upgrade.

2a) Confusion: release notes state that Foo version 3.0 has major performance improvements, why don't I notice anything after upgading to it?..

Thats not a point. People who like to use 3.0 will know from the manual (or an additional note on the package page), that they have to install a new package and not only use 'pear upgrade'.

But PEAR worked the different way for a significant amount of time. This will be a huge BC break. ;]

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...

Old packages have not to be buggy. I think it's naturally for a developer to switch to a new major release of a depending package ASAP. But we can not force people to do that in minutes after release.

Please re-read the part about 'Announcing API changes' that is perfectly implementable without the rest of the RFC.

2c) It will be *necessary* to depend on a *specific* package version after implementing this RFC. It is *possible*, but not *necessary* now.

That's correct. But strict standards have not hurt anyone, yet, did they? Of course the new standard is much more concrete than the old one.

Less choice == good?

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

What should this excuses look like?

"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?

The problem is as I told you above. There may be 2 diefferent packages in PEAR which rely on the same package, but in different versions. To avoid this, the only suitable solution in PEAR is to create different directories for that package. And if a developer likes to use this 2 packages in one and the same file, the naming for a new version has to be changed.

You didn't answer THE ULTIMATE QUESTION. Try again. As for PEAR, this should not be allowed. The packages' authors should either 1) depend on different *packages* (Foo and Foo_v2) 2) explicitly mark dependency on an old version of package (your users can't upgrade and they blame *you*, not dependency's author) 3) make sure your package works with the most recent version.