Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79746
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABRjmp__TD6PjNTiETgD-jSmLSE4cuj7AoOzQh+zmnp6XN5G=Q@mail.gmail.com>
References: <8C1EFD82-CFE0-4D01-9231-2A1658B182A6@ajf.me>
	<CABBJUpfLCjWCgOUneN2O2M7qP2WBf8OgbVrdB-jm+Fn_dDJvVA@mail.gmail.com>
	<CAFMT4NrGBi-YpYz_pOgg=BBhymp5Y4Re9XOwnnY47BTiXA5Oxw@mail.gmail.com>
	<b110fda6282aaf482e7906fcccdb00ab@mail.gmail.com>
	<CAH-PCH5SGuk1L+9y4FBYmdC8GP05UOFnw+iupTy+Av65AGJCnw@mail.gmail.com>
	<c4c3b84eb3b5c5e2451ee3c585fd95c2@mail.gmail.com>
	<EA391654-F731-4B45-9E45-EE780183EEE4@gmail.com>
	<CABRjmp__TD6PjNTiETgD-jSmLSE4cuj7AoOzQh+zmnp6XN5G=Q@mail.gmail.com>
Date: Tue, 16 Dec 2014 22:53:14 +0100
Message-ID: <CAH-PCH7gSeACtJ_YM3hughXqMpPLsTa=w=UPxbo1-6TYL5ZDig@mail.gmail.com>
To: Florian Margaine <florian@margaine.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013d1a64d60abf050a5c62f5
Subject: Re: [PHP-DEV] [RFC] PHP 5.7
From: tyra3l@gmail.com (Ferenc Kovacs)

--089e013d1a64d60abf050a5c62f5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine <florian@margaine.com>
wrote:
>
> Hi list,
>
> I think having a minor PHP version for the only sake of adding E_DEPRECAT=
ED
> is kind of pointless to be honest. Historically, PHP (or other languages
> for the matter, I'm thinking of python) minor versions have brought new
> features. Adding notices is not a reason for a new version imho.
>

please be aware the not everybody agrees on the no new features rule, but
from as I can tell most people seem to agree that no new major features
should be included.
in an ideal world those kind of E_DEPRECATED messages would be there
already before we break or remove a function so there would be no reason
for this discussion.
because this isn't a case I think it is reasonable to have a discussion if
it would worth to have another minor in the 5.x series to make the
upgrading to 7.0 easier.
my proposal was to stop adding minor features into 5.6, create an 5.7 where
those can go and make sure that any(which is possible/feasible) BC break
will be foretold via E_DEPRECATED.


>
> If what we want are notices, and helping people to migrate to PHP 7, then
> we can create tools for this. For example, python made a tool to help wit=
h
> the transition of python 2 to python 3. Go did the same for 0.x to 1.0, i=
f
> my memory serves right. The point of new versions is to include new
> features or bug fixes for the language, static analysis can be done with
> external tools.
>

This is not the first time this idea came up, and some of the BC
incompatible changes in PHP7 already have such tools to spot such usages or
fix them automagically.


>
> The fact that we'll have to maintain one more version is also not somethi=
ng
> to be taken lightly, especially when I see examples of how things progres=
s
> in php-src. (I'm thinking about the recent contributor who gave up.)
>

I think it would be a bit more work, but not that much: 5.4 would stay in
security fix mod until 5.7 is released, 5.5 and 5.6 would be put/kept in
bugfix/security fix mode, new features would only target 5.7 and 7.0.
Merging would be one step longer (for another year) in worst case scenario
(bugfix or security fix) but even that would be less of a PITA if not for
NEWS.
(About the recent contributor gave up stuff: I think that is more of a
problem when the policies/processes are not explicit and/or abused.)


>
> Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then
> it's another matter, and the lifetime of existing versions could be
> extended.
>

That's one reason, which doesn't really require us to do anything, as we
have plenty of time to realize if we want to/have to prolong the lifecycle
of PHP5, and doesn't take much than updating
http://php.net/supported-versions.php and bribing the RMs to cover another
year with the RM stuff.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e013d1a64d60abf050a5c62f5--