I see the same people who had a problem with the EOL (end of life) date for 5.4, 5.5, are going to be the same people who have a problem with 5.6 EOL. Extended the support will only enable those and others to validate their excuse for not needing to migrate to the new code base.
I agree, a date should be made and set. On Mon, Dec 7, 2015 at 8:58 AM, Andrea Faulds <a...@ajf.me> wrote: > Hi Stas, > > 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? >> > > As others have pointed out, there's also the problem of PHP 5 lifetime > extension reducing the urgency for users to move to 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. >> >> > Support for 5.6 ends in August 2017, that's 20 months away. So it's not > quite as bad as that. > > Thanks. > > -- > Andrea Faulds > http://ajf.me/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
