Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89661
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.50 as permitted sender)
References: <d7986bddhrs5d7o2c6r42g6h9to3au5kq0@4ax.com>	<CAH-PCH4_NWEt8WzEhsh1f1SLFnG-NUSJ_BeiSoMP7FsQ2PRpkg@mail.gmail.com>
 <CAF+90c-DCWVNyk+3u-f4drdmh8PbJiip4q=vM775HiTjKFimsA@mail.gmail.com>
In-Reply-To: <CAF+90c-DCWVNyk+3u-f4drdmh8PbJiip4q=vM775HiTjKFimsA@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQHgh9Y9UJHbSHpdKU+NswaLC82f2wIq/m6HAMeq+ueeh+4lMA==
Date: Sun, 6 Dec 2015 19:36:25 +0200
Message-ID: <b739c4a6adcd67f36ff4f20d5b28d189@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, Ferenc Kovacs <tyra3l@gmail.com>
Cc: Jan Ehrhardt <phpdev@ehrhardt.nl>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] PHP 5.6 life cycle
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Sunday, December 06, 2015 7:03 PM
> To: Ferenc Kovacs
> Cc: Jan Ehrhardt; PHP Internals
> Subject: Re: [PHP-DEV] PHP 5.6 life cycle
>
> On Sun, Dec 6, 2015 at 5:32 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
> > 2015. dec. 6. 13:15 ezt =C3=ADrta ("Jan Ehrhardt" <phpdev@ehrhardt.nl>)=
:
> > >
> > > See http://php.net/supported-versions.php
> > >
> > > Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end
> > > of life on 28 Aug 2016? Or will we be postponing this a couple of
> > > months?
> > >
> > > BTW: An end-of-life in Dec 2016 will be in line wih the EOL of
> > > OpenSSL
> > > 1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
> > > http://openssl.org/policies/releasestrat.html
> > > --
> > > Jan
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > > visit: http://www.php.net/unsub.php
> > >
> >
> > Since the rfc for 5.7 failed the voting I've personally assumed that
> > we don't want to support the 5.x series after the normal lifecycle for
> > 5.6:
> > https://wiki.php.net/rfc/php57
> >
> > Most of my arguments for 5.7 was the same as Zeev and orhers listed
> > here in this thread but the majority shared the opinion that the
> > support left for
> > 5.6 is sufficient and we shouldn't prolong the support for 5.x as it
> > will just delay the adoption for 7.0
> >
>
> I can't say anything as to what majorities think, but while I did not wan=
t
> a
> PHP 5.7 release, with the large amount of additional work and
> fragmentation of focus it would have implied, this does not make me
> adverse to extending the PHP 5.6 support cycle. I would go as far as
> saying
> that us not having done a PHP 5.7 release is an argument in favor of
> prolonging support for PHP 5.6, not the reverse.

I agree completely.

Ferenc - the way I see it, 5.7 actually had little to do with the arguments
I brought up.  I believe that the main reason 5.7 was opposed (at least I
can at least speak for myself) is that people felt it wasn't a good idea to
divide our attention from delivering 7.0, something that 5.7 (even if the
only new features were forward compatibility, and more realistically -
packing extra features) would have done.

Sebastian - while it's obvious that us supporting PHP 5.6 for a while longe=
r
does have some effect on migration to 7.0, realistically, we can't force
millions of people to upgrade on our own timeline if it's too short.  On
such a short timeline, what it practically means is that there are going to
be a lot more websites that won't migrate on time and will become insecure
on September 2017.  Also, discontinuing support for PHP 5.6 in August means
you'd have less time to migrate from 5.6 to 7.0 than you did to upgrade fro=
m
5.5 to 5.6 - and that was a painless upgrade.  What if 7.0 was delayed by a
few more months?  Or a year?  Both seemed like likely scenarios back when w=
e
called the 7.0 timeline aggressive.  The 'sin' of the PHP 4 EOL was - well =
-
that we didn't have one for a very long time.  We should definitely have a
clear one for 5.6, but it should be more realistic than 1.5yrs away.

In general, I don't think timelines make sense to commit to before a versio=
n
is released.  If for whatever reason a release gets delayed it makes no
sense that you'd be forced, as a user, for a shorter upgrade cycle.
Something along the lines of Francois' suggestion - where the lifetime of
version N-1 relates to the release date of version N is definitely needed,
and that was the thinking behind the release process timeline to begin with=
.

Zeev