Re: [RFC2] Handling Backwards Compatibility in PEAR
| From: | Stefan Neufeind | Date: | Sat, 20 Sep 2003 15:38:35 +0000 |
| Subject: | Re: [RFC2] Handling Backwards Compatibility in PEAR | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-21844@lists.php.net to get a copy of this message | ||
On 20 Sep 2003 at 11:32, Greg Beaver wrote:
> Stefan Neufeind wrote:
>
> > 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.
>
> This fear is rendered unnecessary by two requirements:
>
> 1) BC is always maintained in minor version upgrades (btw Alexey, your
> clarification is great, can you forward to Lukas?)
>
> 2) users can only rely upon public elements, and these will continue
> to work as documented, so the only breakage that is possible is due to
> a bug, and therefore if a bug exists, pear revert can be used, the bug
> reported on pear.php.net, a new release made, and voila, problem is
> solved.
Well, if we (Alexey and me) mis-understood each other *that* much
then Greg you're right ... and my apologize go to Alexey for mis-
understanding him. The way I understood Alexey was that "a complete
API break" or "complete rewrite" would require a new major version.
But "minor breaks" could be solved also inside the same major
version. And that's what lead me to the point of thinking "hmm,
renaming a function is only a minor break so he didn't want to bump
the major version so users might get into problems".
Alexey, again, if I got you *that* much wrong, apologize. But it's
interesting to see how angry (?) such a discussion can get from one
reply to the other ... maybe we all are a bit too work-overloaded
from time to time. (I know this discussion bugs everybody, discussing
things again and again. But hopefully we'll find a good conclusion
soon that we can all agree upon.)
Stefan