[PHP-DEV] 5.0.5, BC break, fatal error
Pierre Joye
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=3D34468) 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
>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
>
>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
> 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
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
Pierre Joye
On 9/13/05, Andi Gutmans <an...@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=3D34468) 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 behavi=
ors.
- In any case, it should be wroten in a prominent place both in Changelog a=
nd in
the announce text. For example, the 5.0.5 announce only tells that XML_RP=
C=20
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 :-)
Derick Rethans
> On 9/12/05, Zeev Suraski <ze...@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