Liipimaginebundle: [RFC] What version of PHP are you running? What should we require?

[robfrawley]

| Q | A
| --- | ---
| Bug Report? | no
| Feature Request? | no
| BC Break Report? | no
| RFC? | yes
| Imagine Bundle Version | 2.x

I've been reading a lot lately about the trend that most projects continue to support older, and EOL, PHP versions, despite usage/installation statistics showing steadily growing migration away from PHP 5.5 (and even 5.6) in favor of 7.x.

The second trend in installation base is absolutely logical: the newest major release of PHP is much faster and often consumes a lower amount of memory (although to some extent this does depend somewhat on the algorithms used by the application itself).

The first trend, however, does not seem logical. Why are some many package maintainers not bumping their version requirements and utilizing the plethora of language improvements such a move would provide? I don't have an answer, but perhaps those reading this can provide them.

__Whether you are a user or developer, let us know what you're running or what your project's PHP version constraint is, and why.__

I'd like to also find out what the reaction would be to bumping our PHP requirement to 7.x for version 2.0. Before those who rely on an EOL version of PHP freak out, it is important to understand two things: first, this is only an RFC to gather information and no decision has been made; and second, our 1.x code branch will remain compatible with PHP >=5.3 and isn't going anywhere.

What improvements come with a move to PHP 7.x (from our current 5.3 requirement)? Quite a few.

• Short array syntax (I'm so tired of using array())
• Variadic functions
• Array unpacking
• use function and const
• finally blocks in exception handling
• Class name resolution via ::class
• Support for traits
• Function array dereferencing
• Closures with $this context
• Class member access on instantiation (ie (new Foo)->bar())
• Scalar type declarations
• Return type declarations
• Null coalescing operator
• Spaceship operator
• Array constants using define
• Anonymous classes
• Generators
• Generator delegation

So, with all that said, I'll leave you with some numbers to think over, provided by Seldaek via packagist statistics. You can view the original notes on his blog.

| Date | PHP Version | Usage | Change over Time (Percent) |
| --- | --- | --- | --- |
| 2015/11 | __5.5__ | 51% | |
| 2016/05 | | 30% | (41.2%) decrease |
| 2016/11 | | 19% | (36.7%) decrease |
| 2015/11 | __5.6__ | 22% | |
| 2016/05 | | 40% | 81.8% increase |
| 2016/11 | | 37% | (7.5%) decrease |
| 2015/11 | __7.x__ | 01% | |
| 2016/05 | | 20% | 1900.0% increase |
| 2016/11 | | 36% | 80.0% increase |

[garak]

I moved all my active project and all the libraries/bundles I maintain to php>=7.0 a few months ago
I think we need a general initiative to push people, that are still afraid to upgrade, to take such step.
We already seen that in the past, when upgrading to php 5.3

[robfrawley]

FYI: We actually made the decision to require PHP >=7.0 and Symfony >=3.0 in #908, so I agree 100% with your assertion we need to apply pressure on the community to upgrade to modern release and the aforementioned PR reflects this belief.

@antoligy @cedricziel @rpkamp @Koc @makasim I wanted to also check with those active in this project about the prospect of following Symfony and pushing the PHP requirement from 7.0 to 7.1, something that has been brought up by myself and @Koc https://github.com/liip/LiipImagineBundle/pull/908#issuecomment-298700671. Such a move would be in-line with Symfony, which, just five days ago, bumped their minimum PHP requirement to 7.1 in symfony/symfony#22733. The main benefit would be nullable return types, among other things. While nullable return types may seem like a small addition, I've found some of our code quite difficult to add return types to without the ability to enable null returns.

Additional features include:

• void return type
• symmetric array destructuring
• class constant visibility
• iterable pseudo-type
• multi-catch exception handling
• support for keys in list()
• support for negative string offsets
• conversion from callables to closures
• asynchronous signal handling

What does everyone think? We've already made the 2.x branch require PHP 7.0. How do we feel about following Symfony's lead in bumping it one minor version more to 7.1? Let me know all!

[robfrawley]

Just wanted to note, as well, that since we've already required users upgrade to PHP 7.0 for our 2.x branch, that is the hard upgrade for some users who might be running 5.3 or something similar. The move from 7.0 to 7.1 doesn't carry the same difficulty for our users, as they don't have to migrate their code in the same way they may have needed to do for their migration from 5.x to 7.x. It only really requires they grab the latest binary without any code-migration needed.

Just an additional thought I wanted to share.

[makasim]

7.1 sounds good to me.