Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85553
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55193060.5000804@php.net>
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com>
	<55193060.5000804@php.net>
Date: Mon, 30 Mar 2015 15:10:43 +0200
Message-ID: <CAH-PCH6Q7FA536v8qABLSC9C2C0ufXOo2e0eWcB2QfJcLv+gSQ@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>, Stanislav Malyshev <stas@php.net>, julien pauli <jpauli@php.net>
Content-Type: multipart/alternative; boundary=001a113dc5849fee6e051281358c
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a113dc5849fee6e051281358c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 som=
e
> > 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), bu=
t
> > most of the times we simply don't know what to do, and eventually we ju=
st
> > 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).

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a113dc5849fee6e051281358c--