Cakephp: 4.x RFC - PHP7 only?

[inoas]

Is there any update on the core teams stance to only support PHP 7 (or even PHP 7.1 as 7.0 will EOL end of 2018 the same time 5.6 EOLs)?

• Many upcoming framework releases will only support PHP 7: https://thephp.cc/news/2016/12/php-5-active-support-ends-now-what

  NEOS 3.0 will be released in January 2017 and will not support PHP 5
  PHPUnit 6.0 will be released in February 2017 and will not support PHP 5
  TYPO3 CMS 8 will be released in April 2017 and will not support PHP 5
  PhpSpec 4.0 will be released in June 2017 and will not support PHP 5
  Laravel 5.5 will be released in July 2017 and will not support PHP 5
  Xdebug 2.6 will be released in July 2017 and will not support PHP 5
  Symfony 4.0 will be released in November 2017 and will not support PHP 5
  Joomla! 5 is planned for 2019 and expected to not support PHP 5 anymore
  Drupal 9, which is still several years away, is expected to not support PHP 5 anymore

• Stats: https://seld.be/notes/php-versions-stats-2016-2-edition

• PHP 5.6 will only get security patches for 2 more years: https://secure.php.net/supported-versions.php
• CakePHP should appeal and adoption of progressive technology helps with that.

Ref: https://github.com/cakephp/cakephp/wiki/4.0-Roadmap#stay-php-5x-compatible

[dereuromark]

I wouldn't be opposed to it, and all the refactoring recently done in terms of cleaner API also makes it quite possible for 4.x to already leverage lots of the PHP7+ only functionality.
But it only makes sense to limit outselves to PHP7+ if we are in fact using those PHP7+ only features. Otherwise we are doing it for no good reason and that is not a good thing then.

So in general :+1: as long as it is communicated clearly and early on, so people have time to plan ahead their server infrastructure as well as their coding.
And we then introduce strict method typehinting (nullable or not) and parameter typehinting for scalars ideally.

[markstory]

In general I'm ok with only supporting PHP7+. However, I don't want the 4.0.0 upgrade to be a brutal slog like the 3.x upgrade was.

And we then introduce strict method typehinting (nullable or not) and parameter typehinting for scalars ideally.

This is the kind of change that will not only take a _long_ time to do, but will also greatly complicate people upgrading.

If the scope of going 7.0+ is to use new PHP7 features where possible without breaking APIs across the framework then I'm all for it. Strict typing is probably going to be a too hard to do in a way that makes upgrading easier.

[dereuromark]

I am not saying we have to do it all at once, we can gradually do it, e.g. for new functionality.
But it should be allowed to do so IMO at some point when starting to limit ourselves to PHP7+.
Otherwise we are could just as well continue to support 5.6+.

[josegonzalez]

Can we just make 4.0 the last 5.x release and immediately do a 4.1 that requires 7.x (whatever is latest)? That way people still can move forward for a bit.

[phpnut]

Do you think a minor version number we should drop PHP 5? I would prefer to see it done with 4.0 or wait for 5.0

[josegonzalez]

We do something similar with the 3.x series. 4.1 could introduce typehints in key places, no other changes.

[markstory]

@phpnut I think @josegonzalez was suggesting that CakePHP 4.0.0 require PHP >= 7.0.x, and that CakePHP 4.1.0 require PHP >= 7.1.*

[ceeram]

4.0 requiring 7.0 sounds good

People starting new 4.x projects should not start on unsupported php5 versions and those upgrading their framework to 4.x can do it together with a php version upgrade (if needed)

requiring 7.1 imo should not be done until active support of 7.0 (3 Dec 2017) has ended. Being compatible with the latest 7.x is good, requiring it while other minors are still supported does not sound like a good idea to me. just my 2c on the topic.

[dereuromark]

CakePHP 4.0.0 require PHP >= 7.0.x, and that CakePHP 4.1.0 require PHP >= 7.1.*

That makes also most sense to me. Especially since we cannot really use the new PHP strictness features until 7.1 (7.0 is still terrible here), so Cake4.0 and PHP7.0 will just be the entry point into it then.

[josegonzalez]

@ceeram 💯 , just thinking ahead as I don't know when 4.x will come out (I believe @markstory still has a bit of cleanup planned for PSR-7 in 3.5).

[inoas]

@markstory Question: Can we - at this point - commit that 4.x will at least require 7.0 and thus update https://github.com/cakephp/cakephp/wiki/4.0-Roadmap#stay-php-5x-compatible

... and then when more actual work on 4.x is being done the target can be upped from 7.0 to 7.1 or 7.2 (depending on what is stable, generally available and if features help to breath progressive life into CakePHP 4)?

@dereuromark

CakePHP 4.0.0 require PHP >= 7.0.x, and that CakePHP 4.1.0 require PHP >= 7.1.*

That makes also most sense to me. Especially since we cannot really use the new PHP strictness features until 7.1 (7.0 is still terrible here), so Cake4.0 and PHP7.0 will just be the entry point into it then.

So that will mean it will run on 7.1 minimum but not use the strictness features of 7.1? I can't follow on why that makes sense in that regard. It may make a lot of sense to get more adoption, but I am certain it is rather the other way around (if it is fresh and shiny, people will buy into it, even if cakephp4 only uses a single 7.1 feature).

@ceeram

requiring 7.1 imo should not be done until active support of 7.0 (3 Dec 2017) has ended

Do you suspect that CakePHP 4 will be released before that date? I'd even vote for not releasing it before that date. Then we don't have to care about 7.0.

---

PHP 7.1: https://dotdev.co/upcoming-changes-in-php-7-1-76ebea53b820#.61uheop56 look like a lot of features that help at framework level.

[phpnut]

@markstory if that is the case then,
+1 on CakePHP 4.0.0 being PHP >= 7.0.x
+1 on CakePHP 4.1.0 being PHP >= 7.1.*

[markstory]

requiring 7.1 imo should not be done until active support of 7.0 (3 Dec 2017) has ended.

Given our current timelines on getting 3.4 complete, the remaining work for 3.5 and the rough plans we had for 3.6, I don't know if we'll get to a 4.0.0 by Dec 2017.

We had previously planned to have one release (3.6) where all the current deprecations that are documentation only would become runtime errors. The goal of this was to make the migration to 4.0 easier as you could upgrade to 3.6, fix all the runtime errors and then be '4.0' compatible.

Moving the version requirement in 4.0 to >=7.0.x doesn't present any blockers for that approach.

So that will mean it will run on 7.1 minimum but not use the strictness features of 7.1? I can't follow on why that makes sense in that regard.

How would we introduce PHP 7.1 strict typing and still achieve an 'easy' upgrade. I could see us using strict typing in all the new methods we add, but updating existing APIs will be harder. One option could be to start enforcing the documented types where possible.

[inoas]

I have much more pains with silent upgrade requirements during major releases.

So if 4.0 doesn't introduce strict types then IMHO I'd not want to see them in any 4.x release to be able to built apps with semver conventions in mind. However that means that strict types will only be introduced in 5.0 :-/.

Would this help with strict typing https://github.com/cakephp/cakephp/issues/6665 ?

[markstory]

I'd not want to see them in any 4.x release to be able to built apps with semver conventions in mind.

We'd still be able to introduce strict types on new classes/methods. Given the interest in maintaining support for 2.x, it leads me to believe that a number of people are finding it hard to move from 2.x to 3.x, I'd rather not make that significantly worse by adding another complicated upgrade from 3.x to 4.x into the mix.

[BassemN]

IMO, CakePHP should support PHP5.6 until PHP 5.6 reaches its End of Life like Zend Framework. Sorry if this will not sound well to others.

[josegonzalez]

@BassemN We'll almost certainly continue supporting Cake3 with PHP5.x compatibility.

[BassemN]

@josegonzalez If the 3.x branch will be active for security issues then +1 on CakePHP 4.0.0 being PHP >= 7.x

[josegonzalez]

Yep, we will continue to follow the same pattern as we always have regarding security releases. For instance, we continued to make security releases for 1.3.x 5 years after it was initially released. I have no doubt that we'll do similar for the 3.x line.

[inoas]

That's a big reason why cakephp rocks!

[inoas]

Related: Symfony 4 will also be PHP7 only:
http://fabien.potencier.org/symfony4-compose-applications.html

[cleptric]

We updated the Roadmap to 4.0 - https://github.com/cakephp/cakephp/wiki/4.0-Roadmap
It's likely that we won't start with 4.0 before 2018 and active support for 7.0 ends in late 2017, we'll target for php 7.1 in Cake 4.0

[ADmad]

Closing the issue as the decision has been made.