Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85568
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: <5519B77C.5090808@gmail.com>
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com>
	<5519B77C.5090808@gmail.com>
Date: Mon, 30 Mar 2015 23:08:23 +0200
Message-ID: <CAH-PCH6tXjWAkBwEy-6nVBeOMnAV20sEH5AhP3LHzQr98wwwXw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP Internals <internals@lists.php.net>, Stanislav Malyshev <stas@php.net>, julien pauli <jpauli@php.net>
Content-Type: multipart/alternative; boundary=089e01294e80e6b663051287e155
Subject: Re: What's our official stance on small self-contained additions in a
 micro version
From: tyra3l@gmail.com (Ferenc Kovacs)

--089e01294e80e6b663051287e155
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 30, 2015 at 10:52 PM, Stanislav Malyshev <smalyshev@gmail.com>
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.
>
> Adding an option I think it's ok provided it's not controversial and not
> an attempt to create entirely different large functionality hidden
> behind the option (e.g. "let's add an option to make mysql_connect also
> connect to Postgres databases"). If it's something that clearly a small
> functional piece that is missing, adding it I think is OK. If it's
> bigger (like entirely new functionality or substantial change in
> existing one) then it'd be better to go into next version.
>
> > 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.
>
> I'm not sure there's a formal rule that would be good for all cases. We
> can have guidelines but unless we reject all changes completely (which I
> strongly disagree with) I think we'll still have to consider them on the
> substance.
>
>
even agreeing upon something like adding features in a micro version needs
a format RFC and a 2/3 vote would allow us to have a conservative default
while we could still make exceptions with a clear process to follow.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e01294e80e6b663051287e155--