That makes sense with Symfony 4. 馃憤
Since both ubuntu LTS 16.04 and debian stable (stretch) both ship with php 7.0, it seems like a bold move IMO. 馃憥
At least wait for symfony 4
@gorghoa Doctrine recently moved to PHP7.1, Symfony will do the same with the release of the version 4.0 in november. So in all cases, we'll not be able to afford to stay blocked with PHP7.0.
okay okay, let鈥檚 not be stucked like in php 5.3 old days :'D
We will wait anyway for SF 4 IMO, since this will be in 3.0.
Anyway @gorghoa I don't think we should follow the php version shipped in the release of ubuntu or debian, since there are ways to use PHP 7.1 anyway with these Operating Systems.
Here is my plan:
@Filter annotation...) compatible with PHP 7.0 and Symfony 3.As soon as we release a new version, the previous one will be updated only for security fixes to ease the maintainance and encourage people to upgrade.
I don't see a reason to upgrade to 7.2 as I don't see important features there. However 7.1 is a different story.
Next Years LTS of Ubuntu will probably ship with 7.2.
Release | PHP version
-- | --
squeeze 6 | 5.3.3
wheezy 7 | 5.4.45
Jessie 8 | 5.6.29
Stretch 9 | 7.0.14-2
unstable | 7.0.14-2
@soyuka Debian was always to conservative, that's why many people switched to Ubuntu instead.
I know, just my 2 cents. You said many people but sometimes it's not up to you. Personally, I'm using jessie with https://deb.sury.org/ anyway.
Debian was always to conservative, that's why many people switched to Ubuntu instead.
As Debian has always been conservative every single BOFH I know is still using Debian to run his servers. And in special cases where PHP 7.1 is required, or other 'more up to date' packages, there's backports, Sury's PPA and dotdeb. My laptop's dev VM is running Ubuntu.
But then again, who cares. If I need an up to date PHP 7.1 server I just docker run -d php:7.1-fpm anyway. The world is changing ;)
On topic: I don't see any advantage in PHP 7.1 over 7.0 for the time being. I wouldn't consider dropping 7.0 anywhere soon. Optional parameters and return values are nice and all, but not really a reason to drop support for an actively supported and developed PHP version.
But then again, who cares. If I need an up to date PHP 7.1 server I just docker run -d php:7.1-fpm anyway. The world is changing ;)
Then again, not everyone can work with docker :).
@curry684 I do not agree, the type are for me a reason to drop since it can be able to avoid bugs by strong typing the values that that get in and out, we will support 2.x an PHP 7.0 en 3.3 will be on PHP 7.2.
Depending on the timeframe I'm not firmly opposed to staying up to date. I'm actually a strong advocate of that, and I applaud Symfony for switching to 7.1 for upcoming 4.0. However you do have to keep in mind that at that point Symfony will still be supporting 3.4 until november 2020, in all its PHP 5.5 glory. I don't think you should go all out 7.2 in a project of this scope without either a) making a maintenance promise on 2.x or b) waiting for 7.2 to have 20+% practical market share.
Those of us with Docker or being the sysop of their own servers like me won't give a damn about what you require, but it's an open source project with 150k installs - a lot of those are going to be less flexible in their setup and you do not want to alienate them by dropping active support for a platform they'll be locked into for the next 3 years.
The requirement is now PHP 7.1 since https://github.com/api-platform/core/commit/d6ae53cb2453d1049b90326b848754ae7affd5cf
Most helpful comment
Here is my plan:
@Filterannotation...) compatible with PHP 7.0 and Symfony 3.As soon as we release a new version, the previous one will be updated only for security fixes to ease the maintainance and encourage people to upgrade.