Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85694
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuTGYSSMZn2Sh8-ZC5Ae7pK7Ks_q8Lzxt-HoJ8j5Ek-OgQ@mail.gmail.com>
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com>
	<551BC7CF.3080309@birkholz.biz>
	<551C44C7.6060108@gmail.com>
	<551C48AC.3090908@birkholz.biz>
	<551C4A60.2050805@gmail.com>
	<551C5045.3010405@birkholz.biz>
	<551C56E2.8090100@gmail.com>
	<551C5AFB.7090107@birkholz.biz>
	<551C6296.40101@gmail.com>
	<036301d06d61$4e674370$eb35ca50$@php.net>
	<CA+kxMuTGYSSMZn2Sh8-ZC5Ae7pK7Ks_q8Lzxt-HoJ8j5Ek-OgQ@mail.gmail.com>
Date: Thu, 2 Apr 2015 12:41:19 -0600
Message-ID: <CAObuZdsNTeje57qkwxjBfNbqoYOyKbCg8QKP31MAyDqdjmDqiQ@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: francois@php.net, Ferenc Kovacs <tyrael@php.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>, Dennis Birkholz <dennis@birkholz.biz>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1135ea468129af0512c22d9e
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: derokorian@gmail.com (Ryan Pallas)

--001a1135ea468129af0512c22d9e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 2, 2015 at 12:27 PM, Dan Ackroyd <danack@basereality.com> wrote=
:

> Ferenc Kovacs wrote:
> > 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 wil=
l
> > land in 5.5.41).
>
> I think the solution to this is pretty clear, as Rowan put it:
>
> Rowan Collins wrote:
> > - Once a new x.y.0 release is ready, x.y-1.z releases should receive bu=
g
> fixes only. Thus 5.5.x should not be receiving features.
>
> Trying to develop several versions of PHP in parallel causes the
> confusion. If users want new features there is an obvious way for them
> to get them; upgrade their version of PHP.
>

+1 This is exactly it. The longer older versions are "supported" the longer
they remain in the wild.

>
> Levi Morrison wrote:
> > It's not just a pain to document, but there's no
> > real reason to do this because we have minor releases (the Y in X.Y.Z)
> > each year.
>
> This is only true for the past couple of years. This needs to be a
> separate conversation but if we're going to continue to release a new
> minor version each year, and we continue to drop support for previous
> versions, it is a dramatic change to the support lifecycle for PHP.
>
> Getting people to upgrade from an ancient version of PHP to a much
> better PHP 5.4 is acceptable as we can say that it's a much better
> version of PHP. Forcing people to upgrade from 7.0 to 7.3, when it
> will only be an incremental improvement is going to have much more
> resistance from users.
>
> Because of that, I think we may feel pressure to slow down the change
> in minor version numbers. I also just don't seem a problem in adding
> functions in patch versions, so long as there is no BC break.
>
>
> On 2 April 2015 at 16:23, Fran=C3=A7ois Laupretre <francois@php.net> wrot=
e:
> > One example : https://wiki.php.net/rfc/cyclic-replace can probably be
> considered as a 'small self-contained' addition. Should I continue with t=
he
> RFC, respecting feature freeze and proposing it for 7.1, or should I just
> ask the PR to be merged in 7.0 ?
>
> During the discussion of the RFC, several people voiced opposition to it.
>
> Nikita Popov wrote:
> > I'm against this RFC. Not because I don't like the implementation or
> > similar, I simply don't consider this functionality to be sufficiently
> > important to warrant both the additional internal complexity it adds an=
d
> > the complexity it adds to our user-facing API.
>
> So I think this does need an RFC to allow people to vote properly.
>
> And yes, I think the preg_replace_callback_array addition probably
> should have gone to a vote. I know some people have stated objections
> about having too many RFCs - but I think that having a small hurdle to
> adding stuff to core is not a bad thing. If nothing else, it forces
> people to think and describe the changes clearly.
>

I don't see any negative to require RFC to be much more common. It promotes
more communication of an addition, and also helps provide documentation to
users about new features coming through as they can read the RFCs and see
what's approved, rejected, in limbo, etc.

>
> cheers
> Dan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I know I'm new to this list, and its my first response, but I feel like
more transparency is a good thing for the users of PHP.

Cheers!
Ryan

--001a1135ea468129af0512c22d9e--