Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » 5.0.5, BC break, fatal error »

5.0.5, BC break, fatal error

php.internals

Pierre Joye

20 years ago
Hello, Without arguing again about the """fix""" for the memory corruption discovered earlier this summer and without anyone able to reproduce with a medium size script, _why_ in the world one applies this fix to the 5.0 branche? 5.0.5 was supposed to be a _security_ fix release only. I do know many people who will upgrade and they do have tousands of lines of codes wrote by many people. Do you really think the answers given in the various bug reports (http://bugs.php.net/bug.php?id=34468) is good? And please, do not tell me to come with a patch to fix this problem, the fix should have not been applied to 5.0.5, period. Any chance to roll it again without the fix? The fix is not listed in the NEWS neither in the Changelog. I know that the chance to get that fixed is null, but I would like to hear some valid explanations besides the common arrogant answers. Regards, --Pierre

Zeev Suraski

20 years ago
At 01:54 12/09/2005, Pierre Joye wrote:
>Hello, > >Without arguing again about the """fix""" for the memory corruption >discovered earlier this summer and without anyone able to reproduce >with a medium size script, _why_ in the world one applies this fix to >the 5.0 branche? > >5.0.5 was supposed to be a _security_ fix release only. I do know many >people who will upgrade and they do have tousands of lines of codes >wrote by many people. Do you really think the answers given in the >various bug reports (http://bugs.php.net/bug.php?id=34468) is good? > >And please, do not tell me to come with a patch to fix this problem, >the fix should have not been applied to 5.0.5, period. > >Any chance to roll it again without the fix? The fix is not listed in >the NEWS neither in the Changelog. > >I know that the chance to get that fixed is null, but I would like to >hear some valid explanations besides the common arrogant answers.
Pierre, I don't think you're going to get a very good answer here. It boils down to what you already know - it's a bug which results in corruption, and that's the only way to fix it. The common decision was that it's more important to fix this bug than to maintain compatibility, and this even resulted in a new PHP 'family' (4.4). It's one of those cases where there's no good solution, only a choice of bad solutions. Zeev

Pierre Joye

20 years ago
On 9/12/05, Zeev Suraski <zeev@zend.com> wrote:
> I don't think you're going to get a very good answer here. It boils down > to what you already know - it's a bug which results in corruption, and > that's the only way to fix it. The common decision was that it's more > important to fix this bug than to maintain compatibility, and this even > resulted in a new PHP 'family' (4.4). It's one of those cases where > there's no good solution, only a choice of bad solutions.
4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied the patch to 5.1 not to 5.0.5. We did agree to apply it there and not in bug fix releases (and not in security release). Or can you point me to the common decision? ;) The bad solution is to do not communicate about that. Reading the announce of 5.0.5, the only real problem was xml_rpc... If one has asked to apply the fix to 5.0.5, I'm pretty sure nobody will agree to add this fatal error. Regards, --Pierre

Andi Gutmans

20 years ago
Hey Pierre, Mini releases are not only for security fixes. We also do bug fixes, and sometimes even minor functionality (like a new function) which has very low risk of breaking anything. I don't think 5.0.5 is different from that. I do think we could probably be better at communicating these kind of breakages. Question is wether we should just try harder, or if you have some other concrete ideas which would be easy to implement and stick to? Andi At 07:50 AM 9/12/2005, Pierre Joye wrote:

Pierre Joye

20 years ago
Hi Andi, On 9/13/05, Andi Gutmans <andi@zend.com> wrote:
> Mini releases are not only for security fixes. We also do bug fixes, > and sometimes even minor functionality (like a new function) which > has very low risk of breaking anything. I don't think 5.0.5 is > different from that.
As far as (http://bugs.php.net/bug.php?id=34468) exists and have many little brothers, I do think 5.0.5 is very different from that.
> I do think we could probably be better at communicating these kind of > breakages. Question is wether we should just try harder, or if you > have some other concrete ideas which would be easy to implement and stick to?
The implementation is fine, a bug is fixed (whether I had it or not does not matter ;). About trying harder, I will say trying, not bettter, harder, but only trying. My plan before 4.4.0 and 5.1 releases was about being more carefull. Not like I did not say anything or tried to convince those "STFU" people to do so. The steps: - Do not mix security fixes and BC breaks, this is the worst thing one can do. - Do not move from no warning to a fatal error without an intermediate version. For example, 5.0.5 will only raise notices, 5.0.6 and up will have the required behaviors. - In any case, it should be wroten in a prominent place both in Changelog and in the announce text. For example, the 5.0.5 announce only tells that XML_RPC has a security problem, was it on purpose? bad joke? 4.4.0 for that matter was better than 5.0.5. At least it does not always die. But the announcements, communications, or any other normal actions are simply bad, the answers to the bugs report being the worst. So yes, I have had better solutions (from a user point of view), but as you said, it is now too late anyway. But I do not consider that S'ingTFU will help us to be better :-) Regards, --Pierre

Derick Rethans

20 years ago
On Mon, 12 Sep 2005, Pierre Joye wrote:
> On 9/12/05, Zeev Suraski <zeev@zend.com> wrote: > > > I don't think you're going to get a very good answer here. It boils down > > to what you already know - it's a bug which results in corruption, and > > that's the only way to fix it. The common decision was that it's more > > important to fix this bug than to maintain compatibility, and this even > > resulted in a new PHP 'family' (4.4). It's one of those cases where > > there's no good solution, only a choice of bad solutions. > > 4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied > the patch to 5.1 not to 5.0.5. We did agree to apply it there and not > in bug fix releases (and not in security release). Or can you point me > to the common decision? ;)
I didn't even apply it to 5.1, otherwise it would have been a notice there too. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org