Re: [RFC2] Handling Backwards Compatibility in PEAR

Couldn't agree more. Zitat von Stefan Neufeind <stefan@neufeind.net>: > On 20 Sep 2003 at 12:39, Alexey Borzov wrote: > > > Stefan Neufeind wrote: > > > > > This is not what we discussed, right? This way you can't have a 2.x > > > and 3.0 co-exist on a system. For sure this should be no problem on > > > a computer you're working on - but it might become a problem in > > > webhosting-environments. > > > > 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. > Don't take it personally but: Wouldn't such a "you get what you paid > for" and "it's not my problem" be a bit ignorant to the > circumstances? I prefer using a dedicated server or at least a > virtual server myself - but many other people don't. So classical > webhosting is a problem - and as a provider you can run into real big > problems when you upgrade and all customers start getting angry at > you. > > > > You can't just judge on what version > > > installed packages depend but you also need to judge: > > > - if any packages that may need to be installed in the near future > > > depend on the old version - if any apps (that you don't know of > > > because they're not listed in the package deps) still need the old > > > version > > > > 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. > 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. > 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). > > > > Even if you remove one or two functions or rename them you will > > > break BC - and this should, in my eyes, be a new Foo2, v2.0. For > > > sure the dev should consider this version step / API breakage > > > carefully so he doesn't run into version 68.5 after a year :-)) So > > > if the API changes we could suggest that the new API set is thought > > > about carefully and that all plans for the foreseeable future are > > > considered in one (!) API-breakage-step. > > > > 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). Maybe we can assume that people will think this far - > but we should give them a hint to think this way :-)) > > Stefan > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft