Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89714
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56659949.8080405@gmail.com>
References: <d7986bddhrs5d7o2c6r42g6h9to3au5kq0@4ax.com> <11.24.55814.5A495665@pb1.pair.com>
 <56659949.8080405@gmail.com>
Date: Mon, 7 Dec 2015 09:43:49 -0500
Message-ID: <CAFi=QfbYkWmnP75j+rJmD7KuhmwgS-Vq93xBMRCKkW-8Z32JFw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114025ead1f8e105264fe39f
Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycle
From: oldschooldsl@gmail.com (Adam Howard)

--001a114025ead1f8e105264fe39f
Content-Type: text/plain; charset=UTF-8

OS's (CentOS/Debian) for example do offer official upgrade paths via their
own repositories and 3rd party repositories.  However has history has shown
extended support only extends the resistance to update those paths, Alain
Williams

While the PHP Development Team obviously cannot control the actions of
others, it can be influenced by making it clear path regarding when EOL
(end of life) is achieved.


On Mon, Dec 7, 2015 at 9:35 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> Andrea Faulds wrote on 07/12/2015 14:16:
>
>> Furthermore, postponing EOL now means reduced pressure to upgrade to 7.
>> If people feel they do not have to move any time soon, perhaps they won't.
>>
>> So, I wonder if it would not be better to wait until nearer the deadline,
>> and see if we need an extension then?
>>
>
> The problem is, that the genie's out of the bottle - there's been a public
> discussion that the EOL *might* be extended (and realistically it was
> always possible it would be proposed), so just "wait and see" is the worst
> of both worlds: those wanting certainty don't get it, while those who want
> to drag their feet can hope that the decision will go their way in the end
> (a potentially self-fulfilling prophecy, if everyone waits for someone else
> to jump).
>
> There may be value in delaying a final decision, but we need to at least
> make some decisions about the decision:
>
> - If not now, when is the right time to decide? A month before the
> standard deadline is not sensible, because it leads to uncertainty and
> confusion. Maybe at the end of Full Support we decide the length of the
> Security Support? Or maybe just give 7.0 a few months to "bed in"?
> - 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?
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a114025ead1f8e105264fe39f--