Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85554
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAH-PCH6Q7FA536v8qABLSC9C2C0ufXOo2e0eWcB2QfJcLv+gSQ@mail.gmail.com>
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com>
 <55193060.5000804@php.net> <CAH-PCH6Q7FA536v8qABLSC9C2C0ufXOo2e0eWcB2QfJcLv+gSQ@mail.gmail.com>
Date: Mon, 30 Mar 2015 15:28:42 +0200
Message-ID: <CAMUwpuRYMxX9paP0y0-DHAdX4=TX7qeO8wS7Q_9QsU+A3x-rPw@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Michael Wallner <mike@php.net>, PHP Internals <internals@lists.php.net>, 
	Stanislav Malyshev <stas@php.net>
Content-Type: multipart/alternative; boundary=047d7bacb11e565260051281785f
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: jpauli@php.net (Julien Pauli)

--047d7bacb11e565260051281785f
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 30, 2015 at 3:10 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

>
>
> On Mon, Mar 30, 2015 at 1: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")`?
>>
>> --
>> 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

--047d7bacb11e565260051281785f--