Hi, > -----Original Message----- > From: Larry Garfield [mailto:la...@garfieldtech.com] > Sent: Sunday, December 6, 2015 8:01 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.6 life cycle > > On 12/06/2015 11:36 AM, Zeev Suraski wrote: > >> -----Original Message----- > >> From: Nikita Popov [mailto:nikita....@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 <tyr...@gmail.com> wrote: > >> > >>> 2015. dec. 6. 13:15 ezt írta ("Jan Ehrhardt" <php...@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 > > 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?) > > 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. > > 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. > >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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
