Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89722
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5665A087.3040203@lsces.co.uk>
References: <d7986bddhrs5d7o2c6r42g6h9to3au5kq0@4ax.com> <11.24.55814.5A495665@pb1.pair.com>
 <56659949.8080405@gmail.com> <56659ABA.5010708@gmail.com> <5665A087.3040203@lsces.co.uk>
Date: Mon, 7 Dec 2015 12:53:45 -0500
Message-ID: <CAFi=QfaBWF4v+tUqRsOja10XgzzUxLh1OzzPW-Um57Vecbv9rQ@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1140a2ea10cdfb0526528bde
Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycle
From: oldschooldsl@gmail.com (Adam Howard)

--001a1140a2ea10cdfb0526528bde
Content-Type: text/plain; charset=UTF-8

This is the current official timeline
http://php.net/supported-versions.php

I personally think it is long enough and would actually suggestion
shortening it (2016, not 2017).  Extended the timeline would only further
influence people not to upgrade, as an excuse that it was still supported.

On Mon, Dec 7, 2015 at 10:06 AM, Lester Caine <lester@lsces.co.uk> wrote:

> On 07/12/15 14:42, Rowan Collins wrote:
> > Rowan Collins wrote on 07/12/2015 14:35:
> >> - On what factors will the decision be based? If the reason to delay
> >> the decision is lack of information, what information are we planning
> >> to use? Are there metrics we can use to make a more objective decision?
> >
> > Come to think, this works the other way as well: if we *do* make a
> > decision now, are there factors that would allow the question to be
> > reopened? Again, to have any trust in the announced date, people would
> > need to know what these were - if the decision is "probably August
> > 2017", then that would be no decision at all.
>
> At the current time August 2017 is more than reasonable. That some
> distributions produce their own LTS versions, which for example PHP5.4
> has become, just passes the onus to the publisher to act if some serious
> security problem arises post that date. The PHP developers have already
> passed the buck, but I have no doubt if something serious came up which
> needed help from PHP developers they would help out? Certainly my PHP5.4
> distribution still sees security related updates even today.
>
> The point here is that people reliant on older versions of PHP are not
> doing anything wrong, but rather that the official support for that may
> not be via PHP direct. I doubt that PHP5.6 will be an LTS candidate in
> any case, but we need a version of PHP7.0 well bedded in before it can
> be leap frogged and that will hopefully be the situation by August 2016.
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1140a2ea10cdfb0526528bde--