Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85635
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <02f101d06c6e$3790c020$a6b24060$@php.net>
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com>
	<551BC7CF.3080309@birkholz.biz>
	<02f101d06c6e$3790c020$a6b24060$@php.net>
Date: Wed, 1 Apr 2015 13:52:10 +0200
Message-ID: <CAH-PCH7oeAPSR=MnXbx4pf6bOy_QON9exay_68rgbwxNQUqOAg@mail.gmail.com>
To: francois@php.net
Cc: Dennis Birkholz <dennis@birkholz.biz>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b33caf26fa1cc0512a8589d
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b33caf26fa1cc0512a8589d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 1, 2015 at 1:23 PM, Fran=C3=A7ois Laupretre <francois@php.net> =
wrote:

> > De : Dennis Birkholz [mailto:dennis@birkholz.biz]
> >
> > in my opinion all feature changes should go in the next X.Y version and
> > should require an RFC.
> > The reason is that "small self-contained changes" that get pulled in
> > without a discussion on internals and an RFC can easily lead to bad
> > design decisions in the long run.
>
> Correct. The "small self-contained changes" concept easily leads to the
> rules not being the same for everyone.
>

this is what I feel, and one of the reasons for starting this thread.


>
> > I am sorry for the contributor but my example is
> > https://github.com/php/php-src/pull/1145
> > (DateTime::createFromImmutable() method) which was posted here on the
> > list, got three negative replies but was merged nevertheless. I will no=
t
> > reproduce the arguments here but now the door for a clean solution
> > inside the DateTimeInterface seems closed forever.
>
> This example is clearly an RFC released as a PR to bypass the rules
> (discussion, vote, and feature freeze date). I don't understand why it wa=
s
> accepted and merged. Can someone give the rule that was followed in this
> case ? If it should have gone through an RFC, can we revert the change an=
d
> send him back to the RFC process ?
>
>
https://wiki.php.net/rfc/releaseprocess
"No feature addition after final x.y.0 release (or x.0.0). Self contained
features or new SAPIs could be carefully considered on a case by case
basis."
"Bugfixes only (with a room for exceptions on a case by case basis and only
for small self contained features additions)."

The problem is that there is no definition/explanation for the case-by-case
basis.
Does it need a vote? Does it need prior discussion on the thread? Does it
need explicit approval from the RMs?
This problem was brought up in the past a couple of times (the
releaseprocess RFC being too vague here and there also this specific issue
about not having an agreed upon workflow for the approval process for micro
versions), but no resolution was reached so there are examples where we
have lengthly discussion and fullblown RFC for adding a new constant option
to json_encode() while some other feature request just gets merged by an RM
or maintainer of that given extension.

I could accept any decision between holding off new features until next
minor/major and allowing features explicitly without going through an RFC,
but I want to have an explicit definition on what is allowed and how should
the case-by-case process work.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b33caf26fa1cc0512a8589d--