On Mar 30, 2015 6:15 PM, "Michael Wallner" <m...@php.net> wrote: > > On 30/03/15 12:04, Ferenc Kovacs 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. > > > > What do you think? > > > > How about: > > It's okay, if it does not need `version_compare(PHP_VERSION)` but can be > tested by e.g. `defined("SOME_CONSTANT")` or `function_exists("fn")`?
We have php version constants, major, minor and patch. To me it all looks the same, ugly #ifdef like. Now that we release a x.y+1 every year, I do not see the point to continue to force our users to clutter their codes with such tests. > -- > Regards, > Mike > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
