we currently require "phpunit/phpunit": "~9.1" in Flow and "phpunit/phpunit": "^9.6", in Neos, resulting in version 9.6.x being used in both cases. While PHPUnit always promotes a relaxed approach to updates (“No, you do not need to update to the latest version all the time”), this is a problem by now, since:
PHPUnit 9.6 had it’s EOL on February 1, 2019
any PHPUnit below 11 is by now out of bugfixes
Even though any version above PHPUnit 7 is still not EOL, we run the risk of running into deprecations and errors with newer PHP versions.
What is the plan?
Make our unit & functional tests work with PHPUnit 11
Cover everything in the development distributions of Flow and Neos
Work based on Flow & Neos 8.4 (the “later” LTS versions), upmerge to main in the end
Provide documentation for Flow & Neos users with hints on adjusting their own tests
Q: Why PHPUnit 11 and Flow/Neos 8.4?
A: Because that is the only combination where the minimum PHP version matches.
Its also really noble that you plan to back-port / start with this in the Neos 8 branch.
But just for your consideration: I had already some fun with a similar thing where i back-ported the PHPStan introduction to 8.0 and upmerged it kinda. Its sometimes a lot of work and in some case like with the old content repository - in your case its Unit tests - work which will be removed with the upmerge to Neos 9.
I definitely see our problem here with the PHP compatibility. PHP 8.5 is out since a few days and we yet have to verify it works - My PRs to add it to CI in Neos & Flow:
By end of Dezember 2026 PHP 8.6 will be out but by then 8.3 and 8.4 is planned to be in Security only? So if we are compatible with PHP 8.5 right now we might get away with the older phpunit version yet.
For users of Neos and Flow we dont restrict the phpunit version via composer. Users are allowed to install any phpunit version they like. The only thing which might couse trouble in both directions are if our Flow Unit and Functional base test class in in some way incompatible with either a older or more modern version of php unit. But so far im not aware of anything there.
Its definitely your choice to make these are just my 2 ct
Did you have those thoughts after voring yes on the proposal, or afterwards?
Thanks, but I plan to do this as efficiently as possible. So throwing away changed code is not a lot of wasted effort. And at some point we need to update the test code, for whatever branch and towards whatever PPHUnit version.
For users we don’t restrict anything, but people tend to look at our tests for inspiration and guidance, so “promoting” outdated test code seems wrong.
And the thought of relying on PHPUnit 9 for almost two more years (we need to make sure we can run our tests until EOL of our 8.3 versions!) makes my hair stand up.
Plus more reasons I am too lazy to write down now.
Happy refactoring/upgrading then!