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:
On 9/12/05, Zeev Suraski <[EMAIL PROTECTED]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
