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 😄

[Rotzbua]

@damianopetrungaro Here, need php7. I do not think that many people start new projects with an old php version. Also the new debian 9 release use php7.

[silentworks]

@Rotzbua and can you tell me how current version of Slim limits you from using PHP 7? or even how the next version if we chose not to go PHP 7 affects you as a end user please?

[danopz]

@Rotzbua I'm all for PHP7, too, but your statement is difficult. Of course some should start new projects with PHP7, but what if you are limited because of your company, that does just not have accepted new versions, or your hosting provider?

[damianopetrungaro]

All those stuff has been discussed in slack channel.

The point is that the Slim maintainers want to give the opportunity to still use php 5.6 on Slim4 for help developers to migrate from 3 to 4.

As i said imho the Slim 4 should be the "slim of the future" dropping 5.6 support and type hinting as more as possible, as OOP good practices suggest.

Anyway i am not a maintainer, and the maintainers are not stupid people, they know what they're doing 😄

[rotexdegba]

Why not keep Slim 3 active until Dec 2018 as per http://php.net/supported-versions.php (PHP 5.6 stops being supported on Dec 31st 2018 and PHP 7.0 stops being supported on Dec 3rd 2018).

Slim 4 can be developed with a release date of Jan 2019 in mind, this will make it easy to have PHP 7.1 as the minimum required PHP version for Slim 4 and Slim 4 will be able to take advantage of the latest and greatest PHP 7 features. Companies and hosting providers still running PHP 5.6 or PHP 7.0 by Jan 2019 will be running a version of PHP with possible security flaws that won't be fixed and would be under pressure to have at least PHP 7.1 on their servers (by this time anyone still stuck with PHP 5.6 or 7.0 can conveniently keep using Slim 3).

Just my two cents on this issue.

[luispabon]

I would agree with @rotexdegba . Slim 4 is a good opportunity for exactly the sort of breaking changes this thread is about.

In my experience, places that deploy Slim tend to be rather technical and use self-deployed hosting. As a contractor, I haven't used PHP5 once in a single project for a year.

[akrabat]

@luispabon However, we get a lot of support issues related to deployment on shared hosting.

[geggleto]

More people in our eco-system the better! your project can be 7+; it's just Slim will be 5.6+ :)

[rotexdegba]

@geggleto I still believe the slim eco-system can still support people in the PHP 5.6 & 7.0 (and even PHP 5.5) camps by making Slim 3.X an LTS release (with an EOL date of like December 31st 2020) that supports PHP 5.5+ (as it currently does) and actively maintaining it with bug & security fixes and maybe a few lightweight new features. While the new Slim 4.0 would target PHP 7.1+(as per http://php.net/supported-versions.php).

However, if PHP 5.6+ is the final verdict for Slim 4, I will always still be a Slim fan.

[RyanNerd]

Perhaps the biggest argument for requiring PHP 7 for Slim 4 is how error handling is done. Prior to PHP 7 error handling sucks the big wazzo. Consider this code addition to the main app to add Error/Exception handling as middleware. This is simple as pie:

    public function run(bool $silent = false): ResponseInterface
    {
        // Error and Exception handling is now a part of middleware.
        $this->add([$this, 'handleThrowable']);

        // Process the request
        $response = $this->process($this->request, $this->response);

...

    /**
     * Since this is Last In First Executed (LIFE) it is executed first wrapping ALL processing in a try...catch
     */
    public function handleThrowable(
        ServerRequestInterface $request,
        ResponseInterface $response,
        callable $next
    ): ResponseInterface {
        try {
            return $next($request, $response);
        } catch (\Throwable $throwable) {
            return $this->processException($throwable, $request, $response);
        }
    }

[geggleto]

Going to close this. 4.x is 5.6+

[danopz]

As we want to build Slim 4 on PSR-15, which now requires PHP 7 (php-fig/fig-standards#950), we will need to require PHP 7 as well. So I would like to reopen the 5.6 vs 7 discussion.

[geggleto]

.... great.

[damianopetrungaro]

Also related to this: #2259, opened some time ago

[RyanNerd]

PHP 7.0 doesn't allow for optional null return type declarations:

// Not available in 7.0
public function foo(): ?SomeType

Which is an argument in favor of making 7.1 the minimum requirement.

[ndobromirov]

On top of that 7.0 is ending support before 5.6 :)

[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