Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89703
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56651681.8070204@garfieldtech.com>
References: <d7986bddhrs5d7o2c6r42g6h9to3au5kq0@4ax.com> <90c8ecbc29f8a40a2430306b807a169e@mail.gmail.com>
 <5664AC01.1020602@gmail.com> <56651681.8070204@garfieldtech.com>
Date: Mon, 7 Dec 2015 08:42:39 -0500
Message-ID: <CAFi=QfZxYSC7q4dNMkV7Sr0gQWQykH1RJANvP-GJJxutz0V4mQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c37fba09512f05264f0945
Subject: Re: [PHP-DEV] PHP 5.6 life cycle
From: oldschooldsl@gmail.com (Adam Howard)

--001a11c37fba09512f05264f0945
Content-Type: text/plain; charset=UTF-8

Adding extended support does justify (provide an excuse) for others not
adapt or upgrade to new code.  While PHP Development obvious cannot control
the actions of others (obviously), extending support does unintentionally
enables poor practices.  Once support is ended, people do begin to migrate.

I do not believe 5.6 should be given extended support and it should be
treated as any previous release.

On Mon, Dec 7, 2015 at 12:17 AM, Larry Garfield <larry@garfieldtech.com>
wrote:

> On 12/06/2015 03:43 PM, Stanislav Malyshev wrote:
>
>> Hi!
>>
>> IMHO, I think we need to look at the 5.6 lifecycle very differently from
>>> how we look at 5.5 and earlier.  This is really the 5.x lifecycle as it's
>>> the last version that's relatively completely painless to upgrade to from
>>> 5.x (especially 5.3 and later).
>>>
>> We could make 5.6 an LTS release with extended support, but the question
>> is given the code delta, would all fixes' authors be willing to do
>> essentially double work? Would extension authors be willing to maintain
>> two branches long-term? And, if that proves to be hard - wouldn't we end
>> up with a situation where they choose to only maintain PHP 5 version
>> (since it's easier and that's where 90% of people are) and extensions go
>> unsupported for PHP 7 for a long time, creating an adoption problem for 7?
>>
>> I do think we probably need to extend the lifetime of 5.6 (and make an
>> RFC on it) since I see no way to have everybody to adopt PHP 7 in mere 8
>> months, but we should have a defined EOL date ASAP.
>>
>
> Drupal has maintained a current-stable and last-stable version for most of
> its history, with those two versions not being API-compatible.  After the
> first few months, if anything it's the last-stable that gets effectively
> unmaintained by extension developers who want to work with the new shiny.
>
> To be sure, Drupal and PHP are a different dynamic and target audience but
> at least in my experience "only maintain PHP 5 extension, not PHP 7" seems
> like a very unlikely problem, especially once a PHP 7-version of a library
> exists.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c37fba09512f05264f0945--