Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85634
Return-Path: <francois@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 97955 invoked from network); 1 Apr 2015 11:23:09 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 1 Apr 2015 11:23:09 -0000
Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
X-PHP-List-Original-Sender: francois@php.net
X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr  
Received: from [212.27.42.2] ([212.27.42.2:51565] helo=smtp2-g21.free.fr)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 92/20-30489-C15DB155 for <internals@lists.php.net>; Wed, 01 Apr 2015 06:23:08 -0500
Received: from moorea (unknown [82.240.16.115])
	by smtp2-g21.free.fr (Postfix) with ESMTP id 555104B0266;
	Wed,  1 Apr 2015 13:21:10 +0200 (CEST)
Reply-To: <francois@php.net>
To: "'Dennis Birkholz'" <dennis@birkholz.biz>,
	<internals@lists.php.net>
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com> <551BC7CF.3080309@birkholz.biz>
In-Reply-To: <551BC7CF.3080309@birkholz.biz>
Date: Wed, 1 Apr 2015 13:23:01 +0200
Message-ID: <02f101d06c6e$3790c020$a6b24060$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIZ+jDGdyrFO2cHYjlP05/PNTH2cAKYC5AAnJAlKBA=
Content-Language: fr
X-Antivirus: avast! (VPS 150401-0, 01/04/2015), Outbound message
X-Antivirus-Status: Clean
Subject: RE: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> 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.

> 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 =
not
> 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 =
was 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 and send him back to the RFC process ?

Regards

Fran=C3=A7ois