RE: [PEAR-DEV] [RFC2] Handling Backwards Compatibility in PEAR

Simple examples of the need to run two API incompatable versions of the same package have been discussed on the other threads... > -----Original Message----- > From: Alexey Borzov [mailto:borz_off@cs.msu.su] > Sent: Saturday, September 20, 2003 7:03 AM > To: Stefan Neufeind > Cc: pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] [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. :] > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >