On Mon, Mar 30, 2015 at 3:10 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
> > > On Mon, Mar 30, 2015 at 1: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")`? >> >> -- >> Regards, >> Mike >> > > hi, > > That is a good think to keep in mind, but I don't think that is the only > thing matters. > Adding a new function/constants -> there is a chance that we break > somebodys code in a micro version > Adding a new class method -> can be problematic if somebody extended the > class and used the same method but with different signature. > As of now, we don't really consider this kind of things as BC breaks > (otherwise nothing but new optional arguments would be allowed in micro and > minor versions), but it is a PITA for those whose app we break in a micro > version. > I tend to agree that it would be easier for all parties if we stop adding > stuff in micro versions, as it is easier to remember and communicate that > something was added in x.y (as in x.y.0) than the current situation where > some stuff is just only present in 5.6.27, plus this would also eliminate > the confusion, that something is present in 5.6.27 but not in > 5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will > land in 5.5.41). > I agree. That was the case for 5.6 for example, that got added new functions etc... up to 5.6.3 AFAIR. As everything can be considered as beeing a BC break for at least someone on Earth, I admit it is hard to understand the meaning of "small self-contained additions in a micro version" :-p Julien.Pauli
