On Thu, Apr 2, 2015 at 12:27 PM, Dan Ackroyd <dan...@basereality.com> wrote:
> 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. > +1 This is exactly it. The longer older versions are "supported" the longer they remain in the wild. > > 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. > I don't see any negative to require RFC to be much more common. It promotes more communication of an addition, and also helps provide documentation to users about new features coming through as they can read the RFCs and see what's approved, rejected, in limbo, etc. > > cheers > Dan > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I know I'm new to this list, and its my first response, but I feel like more transparency is a good thing for the users of PHP. Cheers! Ryan
