PHPUnit 7

[GrahamCampbell]

No description provided.

[sisve]

I believe that introducing phpunit 7 would make it harder for package developers to maintain stuff for both Laravel 5.5 and Laravel 5.6. Is there any new features in phpunit 7 we need?

[carusogabriel]

PHPUnit 7 uses PHP 7 return and scalar types, and as we don't use it here: 👎

[crynobone]

So we shouldn't upgrade any components that soon adopting to return and scalar type??

[sisve]

@crynobone You're over-interpreting the case here. We can upgrade to the latest phpunit 6, but upgrading to a new major version that uses features we do not use ourselves yet is a bit weird.

[crynobone]

We had the same argument last year when Laravel drop PHPUnit 5.7 and goes for PHPUnit 6. I see no different here, and this is from the person maintaining Orchestra Testbench which is used for package developer to run Laravel tests.

[sisve]

Should we at least wait until the PHPUnit 7 announcement with list of breaking changes? If I read packagist timestamps correctly phpunit 7.0.0 was released four hours ago.

[carusogabriel]

@sisve PHPUnit 7 annoucement https://phpunit.de/announcements/phpunit-7.html

[Dylan-DPC-zz]

And there are no breaking changes from 6 to 7? Surprising

[sisve]

Ah, I was staring at https://github.com/sebastianbergmann/phpunit/wiki.

Sure, there are breaking changes. That's why our travis is failing.

How are package developers expected to target several Laravel releases today? Do we expect them to be able to serve several releases from one branch, or do they need to create a separate branch (and thus release) for every Laravel release?

Does the gains of phpunit 7 compensate for the complexity for package developers to maintain two separate branches with different dependencies for testing?

[crynobone]

If any of the packages developer actually override the single class that are failing here (which is unlikely if you understand the actual code) then yes, you are correct.

That the exact same thing that happen last year with PHPUnit 5.7 versus 6.0 where some of the internal classes need to be updated due to PHPUnit_Framework_* to PHPUnit\Framework\* (not talking about TestCase class here).

[carusogabriel]

@crynobone We are facing PHP 7 method signatures conflicts here, and as Laravel does not use it, PHPUnit 7 is out of scope now

[crynobone]

@carusogabriel that failing class extends PHPUnit\Framework\Constraint\Constraint,, where does Laravel use this class other than testing with PHPUnit??

[carusogabriel]

@crynobone I agree with you. Actually, I'm a huge fan of PHP 7 return and scalar types. But, or we use everywhere, or we don't use. Imagine the amount of PR that will show up if one class starts to use them 😞

[crynobone]

Sure, if one of Symfony components start using return scalar we have to stop supporting newer version, because we depends a lot of Symfony components and we can't have those.

That what you guys trying to suggest here.

[sisve]

We're asking questions that are relevant, and I'm getting the vibes that you're intentionally misunderstanding them to the extreme.

1. Will we still support developers that use phpunit 6 in their projects, or are we telling them that they need to upgrade to phpunit 7?
2. If we support phpunit 6 after this PR, is that support just coincidental in that we do not know of any problems, or is it an intentional decision of supporting phpunit 6?
3. Is this a one-time introduction of scalar typehints, or will we start accepting PR:s that adds them in other places?

[sisve]

Note that I am not asking questions about code. I am asking questions about policies and release management. These are human problems, not code problems. These are decisions that needs to be considered and documented.

We need to be able to say "We intentionally dropped support for phpunit 6 in 5.6" when people ask. We do not want to be put in a decision where we're vague and saying "it probably works, try it and check. we're not sure what version is supported."

[crynobone]

Will we still support developers that use phpunit 6 in their projects, or are we telling them that they need to upgrade to phpunit 7?

No, we aggressively upgrade from PHPUnit 5.7 to PHPUnit 6.0 in Laravel 5.5.0 release. Laravel Framework 5.5 stop testing older PHPUnit (5.0 to 5.7). See #17755 for details.

If we support phpunit 6 after this PR, is that support just coincidental in that we do not know of any problems, or is it an intentional decision of supporting phpunit 6?

Based on history, we stop supporting PHPUnit 6. Package developer can use "phpunit": "~5.7 || ~6.0 || ~7.0" if they want to support multiple versions of Laravel. This has been managed before as we moved from PHPUnit 5.0+ to PHPUnit 6.

Again, if you actually look at the code, none of packages developer would actually override any of those methods.

Is this a one-time introduction of scalar typehints, or will we start accepting PR:s that adds them in other places?

If we need to override Symfony\Component\HttpFoundation\Response:: __construct() which now introduce scalar typehint in 4.0 do we hold off overriding it, do we revert to Symfony 3.4 or do we do it?

[sisve]

The linked issue regarding upgrade to phpunit 6 contains discussion over 20 days before being merged. It seems to be a mess of communication, and it's unclear what we support and doesn't support. There were no authoritative answer on what versions of phpunit we actually support, as you mentioned in the issue.

Just because we did it weird last time doesn't mean we have to do it weird this time.

Regarding the Symfony question, I would have us stay on 3.4 LTS instead of 4.0. The 3.4 LTS will be supported for a few years (4.0 less than a year), there's no reason to upgrade. I believe that Symfony packages will target both 3.4 LTS and 4.0, so there should be versions of those packages we can use if needed. I don't see the need to upgrade to 4.0 at all. In fact, the 4.0 seems to be such huge number of changes that we should probably wait until we can bundle it with a Laravel LTS release just to avoid forcing people writing code that targets two different versions of Symfony.

[crynobone]

My arguments on the original PR because it was first targetting 5.4 (which was on patch support). But as the discussion move forward it was later push to 5.5. PHPUnit later create a release to support namespace aliases in 4.7.28 which allows Laravel 5.4 to continue working on 4.7.

Laravel 5.6 is already pulling Symfony 4.0.

PHPUnit 6.x is going to be support until feb 2019. Assuming we hold off for Laravel 5.6 we still have to either do it in 5.7 or 5.8. And during these time every Laravel developers who use Illuminate\Foundation\Testing\TestCase are locked to PHPUnit 6.x because the tests would failed due to what Travis are showing right now.

[taylorotwell]

Why does what version of PHPUnit that the framework itself uses to test its own code have ANY bearing on package developers? I'm confused.

[taylorotwell]

This isn't very helpful until the problems are fixed. If someone submits a PR please submit after the necessary changes are made to get green tests.