Slim 4 and PHP versions

[Sam-Burns]

More of a question than an issue, but what versions of PHP are to be supported by Slim 4? Has dropping PHP 5 support in the new major version been considered?

[akrabat]

The last time we discussed it, the plan was for PHP 5.6+

[Sam-Burns]

Ok, well if I can't persuade the team to go PHP 7 only, perhaps this PR might be of interest.

[RyanNerd]

Please, in the name of sanity make PHP 7+ a requirement for Slim 4.0

[akrabat]

Why? What do you gain as a user of the framework?

[tabuna]

Require support for PHP 7 reasonably

[RyanNerd]

I'm a user of and a contributor to Slim. The benefits of strict typing alone are self-evident plus the other benefits of version 7 are many.
As a user of the framework, I've had to step through the framework code on multiple occasions to make sure what I was having issues with was my own code and not a flaw in the framework. As an example, PHP 7 has type declarations so expected value types are returned from a function and this helps with the concept of least astonishment. If a function argument is expecting a bool type and a string with the word 'guacamole' is passed instead the issue is immediately obvious -- prior versions instead waste my time forcing me to chase duck typing issues.

If you go even further and insist on 7.1+ you get:

• Scoped constants (which perform better than static declarations)
• Nullable return types
• Negative string offsets
• The void return type
• more

And for any PHP dev that may have been living in a cave for the past two years here are the new features of 7.0:

• Scalar type hints
• Return type declarations
• Anonymous classes
• The Closure::call() method
• Generator delegation
• Generator return expressions
• The null coalesce operator
• The space ship operator
• Throwables
• Level support for the dirname() function
• The Integer division function
• Uniform variable syntax

[Sam-Burns]

With basic security support for PHP 5.6 and 7.0 ending next year, and bug-fixing for PHP 5 already gone, it would be nice to see Slim users encourage to upgrade. For those who can't, maybe a good period of support for Slim 3 might be an option. Perhaps this could be an alternative to developing the latest version of the Slim framework in an old language version?

[RyanNerd]

@Sam-Burns good points! I'd like to see Slim 3 become the LTS version (getting security patches and minor bug fixes) with Slim 4 becoming the next stable release that requires the current stable release of PHP.
Note: Xdebug is one of the first extensions to start exclusively targeting 7+ (only fixing minor bugs or security patches in older versions of the extension). What I'm saying is that Slim would not be alone in requiring PHP 7+.

[geggleto]

@RyanNerd the problem with that is that the PSR standards are going to be changing later this year which is why we are building Slim 4.

[geggleto]

for the record: for the most part, I am supporting Slim 2 and Slim 3 as I have production applications in use right now and clients that do not want to upgrade ;)

[RyanNerd]

@geggleto I was unaware of the PSR standards changing and this being the underpinnings of why Slim 4 is being created. Has the specification for the changes been solidified and published? Is this specifically for PSR-7 or ALL PSR standards are getting overhauled?

Also, I'm not sure why a change in PSR standards would prevent PHP 7 as a requirement?!?

[RyanNerd]

Also, for the record, I am supporting Slim 2 and Slim 3. My group v1 routes to Slim 2 and group v2 routes to Slim 3 (We deploy Slim 3 which has backward compatibility to Slim 2). We would need to do an in-place full upgrade and deprecate groups v1/v2 if Slim 4 was to not be backward compatible with previous versions.

I'm okay with doing this if PHP 7 is required -- as the gains from this version of PHP outweigh the pain points for upgrading for me personally -- (I'm a bit grumpy about this because of the time I've spent stepping through the Slim framework trying to determine where things are breaking down knowing if PHP 7 were in place I would have better knowledge and expectations of what is going on inside the framework).

Since I'm the only person that really matters and all cases should cater to my desires... JK -- I know I'm not the only use case and the whole picture needs to be viewed when it comes to a framework.

BTW -- Great work everyone on the Slim team! Your framework is a godsend.

[akrabat]

There's no reason why you can't use PHP 7 with Slim 2, 3 and 4.

The question is whether we should exclude people who are on PHP 5.6 which is getting security updates until December 2018.

[juliangut]

I add to @RyanNerd question to @geggleto. How are PSR changing later this year? which ones?

[akrabat]

https://github.com/php-fig/fig-standards/blob/master/proposed/http-middleware/middleware-meta.md

[juliangut]

Ahh

It's not a change in a PSR but the approval of the new middleware PSR (some projects are already using Interop version in preparation).

I was misled to thinking some approved PSR was going to change and I was like: what?!? Thanks

[RyanNerd]

Thanks for the clarifications. Still hoping that internally Slim 4 makes PHP 7 a requirement.

Dang. I just recently got my head wrapped around the double pass middleware approach (really liking it) and already a standards proposal that completely does away with the double pass methodology. Ah well, if you don't like change then the IT sector is not for you.

[damianopetrungaro]

@silentworks i answer here about #2223

Sure php 5.6 is still supported, but will php 7 introduce many feature that makes it so much more stable and the scalar/return type declaration are the main one imho.

See that Slim 4 is the "next" version of Slim 3 i would like to see as more as possible support for the really "next" php version.

PHP 5.6 is going to die next year, and supporting it right now, will garantee a very important BC.

If we add a PHP 7.X only support there will be also less tests for wrong parameters/return type.

If PR is needed i can help to add scalars type and return type.

I am supporting so much the scalar/return type declaration feature because is the main one that will be apprecciated and will give us a really good support for stability and mantainability

[damianopetrungaro]

Nobody reply to this important topic?

[akrabat]

Nobody reply to this important topic?

There's nothing to add at this stage. @silentworks and myself (& possibly @codeguy?) are comfortable with PHP 5.6 as the minimum version and until someone persuades us otherwise (or we change our minds) Slim 4 will be 5.6 +.

Of course, we're many months from release, so it's possible (maybe probable?) that this will change.

[damianopetrungaro]

@akrabat how are you going to handle the end of support of PHP 5.6 in the Slim4?
Because it will bring a lot of BC/refactoring imho.
In my mind is better think to this stuff now and not after.

[damianopetrungaro]

The discussion continued in the slack channel, and @akrabat & @silentworks at the moment don't think is an essential feature.

The solution is that Slim 4 will support php5.6 and a possible Slim 5 will drop the 5.6 support, and will be refactored using php7 new features.

The "php7 only support" will possibly be introduced only if a lot of users require it.
😄

At this point i agree with the two tagged maintainers, is not an "evil" idea their point of view.

[RyanNerd]

@damianopetrungaro Thanks for the update. I'm disappointed but understand the decision to keep support at php5.6 for Slim 4.
So the debate doesn't linger on, this issue should probably be closed if this is actually the decided resolution. Reopen this as a new issue when Slim 5 is ramping up.

[damianopetrungaro]

As i said:

The "php7 only support" will possibly be introduced only if a lot of users require it.

So imho it can stay open 😄

[l0gicgate]

I think that we should go with 7.1. Slim 4 introduces a few breaking changes already.

This reminds me of Internet Explorer support (which all front end devs still suffer from), there is absolutely no point in supporting 5.6/7 after EOL. Slim 4 isn’t on track to be released before Q1 2019 at this pace anyway.

If your hosting provider doesn’t let you use PHP 7.1, then you should switch as it is a security concern. And for people who are going to migrate projects from Slim 1/2/3 you’re already refactorIng the whole project. Just do it the right way.

[tuupola]

Although I think using nullable return types is a bad idea, I am also proponent of going directly with 7.1.

[damianopetrungaro]

PSR-15 requires php >=7.0, we can go with PHP 7.0 and do not use nullable types.

It depends when we are going to release the v4, if it's 2019 PHP 7.1 imho it's ok otherwise 7.0.
As said few months ago i am pretty free to add all types and signature to the codebase, in an half days it may be done.

[luispabon]

I know it's not exactly an argument, but other frameworks have skipped 7.0 altogether, like symfony (and by extension laravel), also phpunit requires 7.1 now. There's no point today in starting any new projects in 7.0, and slim 3 works just fine with it.

[luispabon]

Also, I think it's important to point out that keeping up with php updates is not what it used to be due to a lot of places switching to docker based deployments. Again, people locked up in php7.0 because of problematic server upgrades or shared hosting still have slim 3 available and working perfectly.

[Rotzbua]

I proposed a pull request #2404 increasing php version to 7.0. So we can make the first step and get rid of 5.6 for slim4.

[odan]

Let's take a look at the Ubuntu LTS releases.

PHP 7.0.4 is the default PHP package in Ubuntu LTS 16.04 (Xenial Xerus)
End of Life date: April 2021 !

PHP 7.2.x could be the default PHP package in Ubuntu 18.04 LTS.
Release date: April 2018.

I believe there is a big LTS user base and we should not just ignore this group.

Symfony 4.0 requires PHP >= 7.1.3
Laravel 5.6.0 requires PHP >= 7.1.3
Zend 2.4.13 and Zend Expressive requires PHP ^5.6 || ^7.0

PHPUnit 6 requires PHP >= 7.0
PHPUnit 7 requires PHP >= 7.1
PHPUnit 8 (not released) requires PHP >= 7.2

[luispabon]

Ubuntu 16 users still have slim 3 available. If slim 4 released today, I'd totally get the point, but how close are you guys to RC status?

I guess the main question is whether you want to burden yourself with maintaining compatibility with versions of PHP that are to be deprecated fairly soon.

Nullable types in 7.1 are great, but the void return type is more to the point IMO, especially when tightening up interfaces.

[odan]

@luispabon You are right. I'm tending to PHP >= 7.1.3.

[ruslan-avantis]

The growth of the version and the growth of requirements.
This is the only correct way.
Slim 3 ^ 5.6 || ^ 7.*
Slim 4 ^ 7.2

[zelding]

My vote is on 7.1+

Just the scalar type declarations are a good start, but imho the return type declarations are not good enough without the ability to define them nullable

that is my main reason

[akrabat]

Slim 4 is now going to be PHP 7.0+. I don't mind going to PHP 7.1 if someone can demonstrate either

a. some code in Slim 4.x branch that could be measurably better using a feature in PHP 7.1
b. a dependency of Slim 4.x has a minimum version of PHP 7.1

Raise an issue in these cases.

[rotexdegba]

http://php.net/supported-versions.php. Php 7.0 is no longer going to be supported starting December 2018. This is a very good reason to make php 7.1 the minimum version for slim 4.