Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89669
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Larry Garfield'" <larry@garfieldtech.com>,
	<internals@lists.php.net>
References: <d7986bddhrs5d7o2c6r42g6h9to3au5kq0@4ax.com> <CAH-PCH4_NWEt8WzEhsh1f1SLFnG-NUSJ_BeiSoMP7FsQ2PRpkg@mail.gmail.com> <CAF+90c-DCWVNyk+3u-f4drdmh8PbJiip4q=vM775HiTjKFimsA@mail.gmail.com> <b739c4a6adcd67f36ff4f20d5b28d189@mail.gmail.com> <566485DD.7010504@garfieldtech.com>
In-Reply-To: <566485DD.7010504@garfieldtech.com>
Date: Sun, 6 Dec 2015 20:38:18 +0100
Message-ID: <012901d1305d$aa68ed30$ff3ac790$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHgh9Y9UJHbSHpdKU+NswaLC82f2wIq/m6HAMeq+ucCFzVLDwJ+ORzvnmNiBBA=
Content-Language: en-us
Subject: RE: [PHP-DEV] PHP 5.6 life cycle
From: anatol.php@belski.net ("Anatol Belski")

Hi,

> -----Original Message-----
> From: Larry Garfield [mailto:larry@garfieldtech.com]
> Sent: Sunday, December 6, 2015 8:01 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] PHP 5.6 life cycle
>=20
> On 12/06/2015 11:36 AM, Zeev Suraski wrote:
> >> -----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
> >> want 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
> > longer 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 from
> > 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 we 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
> > version 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
>=20
> Coming from user-space, +1 to the "an extra year over whatever it =
would have
> had" for the last release within a major.  While I'm champing at the =
bit to use
> PHP 7 and will be trying to push others to do the same, realistically =
it is a
> bumpier upgrade than 5.5->5.6 (duh) so giving people extra breathing =
room to
> plan an upgrade is a good thing.  Whether that's an extra year of =
active support
> or security support, I don't feel strongly.  (Maybe making it security =
support will
> be a better upgrade
> incentive?)
>=20
> That said, I also agree that a fixed date is mandatory, or people =
won't feel any
> pressure.  The drop-dead date is important for planning and messaging, =
just as
> we saw with GoPHP5.
>=20
> That extra year is also helpful to all the big projects that just =
increased their
> minimum version to 5.5.  (Drupal, Symfony, Zend Framework, Guzzle, =
etc.)  I
> expect most projects are going to skip 5.6 as a minimum required =
version and
> jump straight to 7, just like many skipped 5.4, but they'll need to =
see more server
> offerings.  It will be an easier case to make in 2 years for the next =
version of all
> of those projects to go to 7.x if 5.6 is sec-only with a known =
drop-dead date, but
> not entirely abandoned so we have some breathing room until then.
>=20
From today's perspective, I'd suggest to extend the security only period =
of 5.6. Virtually, most of the core devs are concentrated on improving =
and bringing forward 7. That means what is called "active development" =
doesn't really match the reality, per fact. And per the tendency, that =
could most likely get ever more obvious.

Clear, there will be always customers not willing to upgrade, just like =
today there are quite some still running even PHP 4. However those are =
real legacy applications which can't be supported endlessly, and it is =
well known. Telling that 5.6 will stay stable and secure for the =
extended security only period is probably honest and fair with respect =
to both the core devs and to the users.

Most likely the end decision would make sense to be evaluated in summer =
2016 when the developments in the real world are evident. It could be, =
that an extension is not required. Or it could be, that the "active =
development" phase is required to continue very much. We also depend =
very much on the decisions of other projects, be it distributions or PHP =
core dependencies.

Regards

Anatol=20