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
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
