On Sun, Nov 30, 2014 at 8:33 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: > On Sun, Nov 30, 2014 at 8:09 PM, Rowan Collins <rowan.coll...@gmail.com> > wrote: > >> On 30/11/2014 18:06, Remi Collet wrote: >> >>> >However, I think we should stop including features in our patch >>>> >releases. I've heard a few others express similar sentiment, but >>>> >it may have been more targeted at what we are allowing for "bug >>>> >fixes" in patch releases. Anyway, that's my input. >>>> >>> Yes, I'm one wanting to reduce new feature in stable branch... >>> >>> This is the reason why I propose this feature for 5.6 (not 5.5) and >>> with a new option to not change default build. >>> >> >> But that's still technically introducing a feature in a patch release. >> >> From a documentation point of view, it's a lot tidier if we only ever have >> to say "since PHP x.y" rather than "since x.y.z", and as you say, there's >> always a risk. I don't know much about this case, but let's say a mistake >> allowed a misconfigured build to apply an inadvertently wide ACL; having >> that emerge in a patch release could mean downstream maintainers losing >> faith in the official releases, and make everyone's lives harder. >> >> Part of the stated aim of the release process RFC [1] was to "reduce the >> time to get new features in a release", and the solution to that was to >> guarantee a release every year, so that there's never more than a few >> months to wait, while simultaneously having clean, safe, patch builds. The >> crucial paragraph is this: >> >> > No feature addition after final x.y.0 release (or x.0.0). Self contained >> features or new SAPIs could be carefully considered on a case by case basis. >> >> That wording implies - in my opinion - that the burden of argument should >> be on the feature's sponsor for why an exception should be made, but >> there's a temptation to shoot for inclusion everywhere and see if the RM >> challenges it. >> >> [1] https://wiki.php.net/rfc/releaseprocess > > > this is also my interpretation(that is should be of a case-by-case approval > process instead of a RMs can veto if they really want), but I seem to be > the minority on this side. > having said that, I would be fine having this one in 5.6.x.
For me, this feature is self contained, and even benefit from an activation switch (--with-fpm-acl) , saying it will not change the codebase if not activated. So it may be included in 5.6 However, I agree that it's bad to have : "from 5.6.Z , you may use FooBar feature", better to have "from 5.6". Having patches introducing new features in revision versions is hard to remember and bad for versionning Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
