Re: [RFC2] Handling Backwards Compatibility in PEAR

Hi! First of all: I think Greg's RFC addresses the BC breakage problems for the PEAR developers and "direct" users just fine. I don't quite see why PEAR developers must address the problems of other (possibly quite numerous) people, while these people do nothing about their problems themselves. Stefan Neufeind wrote:

Lets say this loudly: if you want to fully control your environment, you'll need to keep a private copy of PEAR. If you are using a hosting that does not allow this, tough luck. You get what you pay for, generally.

Agreed. But you can't say "well, your provider upgraded and now the app doesn't run anymore? your problem.". That's not possible. And as a provider you will always get questions like "was the update necessary" and "everything ran fine - so why did you update" etc. For sure you have to update to keep pace with the development and all new features introduced in newer versions. But you will have a hard time with all customers who's apps you break. And you can't fully retest every app nce you've updated.

Lets overview possible hosting scenarios: 1) Your *private* application depends on *public* PEAR install. PEAR installer can not now handle such a dependency and probably never will. It is *your* problem if anything breaks. 2) Public application depends on public PEAR install. Already existing infrastructure can prevent breakage. 3) Private application depends on private PEAR install. Ditto.

I think it is not feasible. If a new version of, say, glibc comes out Linux ditributors do not do clever hacks to make old and new glibc versions co-exist. They simply rebuild the existing packages for the new glibc. Why shouldn't we do the same?

a) Because it's not a simple "rebuild" like with most c-sources. You need to change tha API accordingly.

You generally wouldn't need to change API, but to check whether everything works OK and re-release your package with updated dependencies. A PEAR analog of building an rpm.

b) You don't have everything centralised like a Linux distributor has. A distributor knows all the packages he ships and can therefor make adjustments so that on the day he releases a new glibc he also provides the other packages in an updated form.

And application authors depending on PEAR can do exactly that and provide customized versions of PEAR packages. What? It actually requires some *work*?! Horror! I think having f.e. Package/Foo.php Package/Foo.Horde.php is *much* better than having f.e. Package/Foo.1.2.3.php Package/Foo.1.2.4.php Package/Foo.1.3.0.php Package/Foo.2.0.php As in the first case both files will likely be used, while in the second one they just take up space and add to general confusion.

c) We're not only talking about packages but also about apps. And you can't judge about all apps on your server. Maybe some even are only available in bytecode (refering to as 'encoded', because they might be commercial PHP apps shipped without source).

The above is especially true for commercial vendors. They can even distribute PEAR packages in encoded form, as most licenses used in PEAR allow this.

Package maintainers tend to change. Careful planning will not help here.

Okay, if maintainers change you're right. But what I intended was to make people think carefully that they don't change the name of a function (and by this break API and require a new major version) and a month later they rename another function (bumping the major version by 1 again).

Completely agree here. But I haven't yet seen a package in PEAR that is developed that way. :]