> -----Original Message----- > From: Nikita Popov [mailto:nikita....@gmail.com] > Sent: Monday, October 12, 2015 10:33 PM > To: Anatol Belski <anatol....@belski.net> > Cc: Dmitry Stogov <dmi...@zend.com>; PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by > ReflectionFunctionAbstract::getClosure() > > On Mon, Oct 12, 2015 at 10:22 PM, Anatol Belski <anatol....@belski.net> > wrote: > > > Hi, > > > > > -----Original Message----- > > > From: Nikita Popov [mailto:nikita....@gmail.com] > > > Sent: Monday, October 12, 2015 8:57 PM > > > To: Dmitry Stogov <dmi...@zend.com> > > > Cc: PHP internals <internals@lists.php.net>; Andrea Faulds > > > <a...@ajf.me>; > > Stas > > > Malyshev <smalys...@sugarcrm.com>; Bob Weinand <bwo...@php.net>; > > > Anatol Belski <anatol....@belski.net> > > > Subject: [PHP-DEV] Re: Forbid rebinding scope of closures created by > > > ReflectionFunctionAbstract::getClosure() > > > > > > > It would be great, if we stop any commits into PHP-7.0 except for > > > critical fixes now > > > > > > Maybe keep PHP-7.0 open (or as open as release branches usually > > > are), > > but from > > > now on only cherry-pick critical fixes into PHP-7.0.0 (instead of > > > merging everything)? > > > > > I commit myself to Dmitry's words. What matters today and especially > > after > > RC5 is the stability. Today we should invest into testing and bug > > fixes more than into improvements (aka fixes to something that is not > > broken). It really matters for the quality of the final. That's the > > message to convey probably. > > > > To rephrase my question: Should we treat PHP-7.0 the same way we treat > PHP-5.6 and other release branches (i.e. all kinds of bug fixes are okay, > even if > it's just improving a test or fixing some inconsequential behavior), or do you > want to limit the PHP-7.0 branch to actually critical fixes now? From what you > say, I assume the former rather than the latter? > Talking about "critical" I meant usual definitions as something that causes memory corruptions, data loss, big functional impact, security flaws, etc.
The tricky point with 7.0 right now is that it's a lot of new stuff with very high expectations standing short before final. Coupling this with the "critical" from above, the definition I would make were - it is a) critical and b) can be fixed properly and cannot wait until after the final release. The dev time spent to fix something after 7.0 final is indeed lost for the 7.0 final. Any new code short before final increases the instability risk of the final. Fe small functional regressions are probably not always critical. If a (even small) functional regression breaks a lot, it is critical. If a functional regression breaks a rare use case - it is not critical. If improving a test helps to cover some critical code - so yes, it is critical as well. Anything that is critical can involve anything you've mentioned like adding tests or code. Hopefully I could express myself better now. Cherry-pick is of course a solution, but IMHO it is important every dev to understand the unique situation we currently have to face. It is better to avoid cherry-picking in favor of the "mission aware" code :) Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
