Ferenc Kovacs wrote: > this would also eliminate > the confusion, that something is present in 5.6.27 but not in > 5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will > land in 5.5.41).
I think the solution to this is pretty clear, as Rowan put it: Rowan Collins wrote: > - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug > fixes only. Thus 5.5.x should not be receiving features. Trying to develop several versions of PHP in parallel causes the confusion. If users want new features there is an obvious way for them to get them; upgrade their version of PHP. Levi Morrison wrote: > It's not just a pain to document, but there's no > real reason to do this because we have minor releases (the Y in X.Y.Z) > each year. This is only true for the past couple of years. This needs to be a separate conversation but if we're going to continue to release a new minor version each year, and we continue to drop support for previous versions, it is a dramatic change to the support lifecycle for PHP. Getting people to upgrade from an ancient version of PHP to a much better PHP 5.4 is acceptable as we can say that it's a much better version of PHP. Forcing people to upgrade from 7.0 to 7.3, when it will only be an incremental improvement is going to have much more resistance from users. Because of that, I think we may feel pressure to slow down the change in minor version numbers. I also just don't seem a problem in adding functions in patch versions, so long as there is no BC break. On 2 April 2015 at 16:23, François Laupretre <franc...@php.net> wrote: > One example : https://wiki.php.net/rfc/cyclic-replace can probably be > considered as a 'small self-contained' addition. Should I continue with the > RFC, respecting feature freeze and proposing it for 7.1, or should I just ask > the PR to be merged in 7.0 ? During the discussion of the RFC, several people voiced opposition to it. Nikita Popov wrote: > I'm against this RFC. Not because I don't like the implementation or > similar, I simply don't consider this functionality to be sufficiently > important to warrant both the additional internal complexity it adds and > the complexity it adds to our user-facing API. So I think this does need an RFC to allow people to vote properly. And yes, I think the preg_replace_callback_array addition probably should have gone to a vote. I know some people have stated objections about having too many RFCs - but I think that having a small hurdle to adding stuff to core is not a bad thing. If nothing else, it forces people to think and describe the changes clearly. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
