Re: [RFC2] Handling Backwards Compatibility in PEAR

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