Re: What's our official stance on small self-contained additions in a micro version

From: Date: Mon, 30 Mar 2015 11:36:08 +0000
Subject: Re: What's our official stance on small self-contained additions in a micro version
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-85550@lists.php.net to get a copy of this message
On Mar 30, 2015 6:15 PM, "Michael Wallner" <mike@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 >

« previous php.internals (#85550) next »