On Mon, Mar 30, 2015 at 4:04 AM, Ferenc Kovacs <tyr...@gmail.com> wrote: > Hi, > > I know that our official release process allows that, but there are some > reasonable arguments against doing that and this topic was brought up > multiple times related to specific fixes. > I have two open PRs like that: > https://github.com/php/php-src/pull/1204 > https://github.com/php/php-src/pull/969 > and of course there are a bunch of similar ones from other people, and > there are cases when somebody simply pushes a change like that, other times > somebody points out that it should require an RFC( > https://wiki.php.net/rfc/json_preserve_fractional_part for example), but > most of the times we simply don't know what to do, and eventually we just > let the PR/patch to rot and die. > I would like to know if we can come up with a rule which can have consensus > behind it, and maybe formalize it as an extension to our current > releaseprocess rfc.
I personally do not want to see *any* features go into a patch release (the Z in X.Y.Z). 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. I'd even like to tighten up on what "bug fixes" we allow into patch releases, as I think we have been far too accepting in the past. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
