Keep full PHPUnit 9.x support

[mvorisek]

revert #416

"run in separate process" has an issue on PHP 8.3+

the issue has nothing to do with this package compatibility, phpunit 9.x is fully compatible

related with #368 and #369

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (3ddec39) 66.66% compared to head (2f86dfa) 66.73%.

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #417      +/-   ##
============================================
+ Coverage     66.66%   66.73%   +0.07%     
  Complexity       92       92              
============================================
  Files            21       21              
  Lines           459      460       +1     
============================================
+ Hits            306      307       +1     
  Misses          153      153              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[localheinz]

But why, @mvorisek?

Who in their right mind will not update phpunit/phpunit:^9.0.0 to the latest version of phpunit/phpunit:^9.6.15?

[mvorisek]

Imagine project like this one /w slow test detector dependency.

If this package/dependency will limit the phpunit version, lowest testing will be constrained more than needed. Therefore this PR.

[localheinz]

If this package/dependency will limit the phpunit version, lowest testing will be constrained more than needed. Therefore this PR.

Again, why would anyone want to use phpunit/phpunit:9.0.0 when they could use

• phpunit/phpunit:9.0.1
• phpunit/phpunit:9.1.0
• phpunit/phpunit:9.6.15

I can't see a problem with limiting use to versions of phpunit/phpunit that do not have known bugs.

And, when we start patching phpunit/phpunit in test runs, where do we stop?

[mvorisek]

Normally, phpunit/phpunit package is added/used as dev package where is does not matter much. But when this/slow-detector package is used together with some project requiring phpunit/phpunit package as non-dev, such project should not be limited by requiring slow detector. So please, let's keep full 9.x and 10.x support. The slow detector is 100% compatible.

[localheinz]

@mvorisek

Do you have examples of such packages?

[mvorisek]

In short any PHPUnit lib. composer.json example:

{
    "require": {
        "php": ">=7.4 <8.4",
        "phpunit/phpunit": "^9 || ^10"
    },
    "require-dev": {
        "ergebnis/phpunit-slow-test-detector": "^2.4"
    },
}

When "lowest" packages are installed for PHPUnit testing, the ergebnis/phpunit-slow-test-detector must have zero or minimal constraints, otherwise the trully tested packages will be different than the trully supported.

[localheinz]

@mvorisek

I have understood, but I would like to see an actual package where that would be a problem to avoid solving problems that aren't problems.

[mvorisek]

I am describing our internal testing package. With the composer.json above and composer update --prefer-lowest command PHPUnit 9.0.0 must be installed. This is what this PR does.

This/slow detector package is thankfully fully compatible. We can avoid the patching by testing PHP 8.3 /w higher PHPUnit, but I have choosen to patch PHPUnit to make the testing (of this package) as best as possible.

[localheinz]

@mvorisek

I am describing our internal testing package. With the composer.json above and composer update --prefer-lowest command PHPUnit 9.0.0 must be installed. This is what this PR does.

And which of your internal packages or applications that use your internal testing package really need to use phpunit/phpunit:9.0.0 and why?

[localheinz]

@mvorisek

Perhaps your company can request an invoice for accepting this patch - and if you want me to, I can choose an amount that

• either covers the pain of accepting such a patch
• or is high enough that your company stops using phpunit/phpunit:9.0.0 and instead uses at least phpunit/phpunit:9.4.3

By the way, bug fix support for phpunit/phpunit:^9 ends soon, too:

[mvorisek]

And which of your internal packages or applications that use your internal testing package really need to use phpunit/phpunit:9.0.0 and why?

#417 (comment) is strong example. When a package claims it does support some deps, the deps must be really supported and tested. Dev packages must imply minimal side effect to the testing, in this case, not prohibit to install PHPUnit 9.0.0 - 9.4.2.

[localheinz]

@mvorisek

So you will not be requesting an invoice?

[mvorisek]

Andreas, thank you for bringing this topic up again and addressing the elephant in the room. I saw your ergebnis/composer-normalize#1236 (comment) comment where you came up with the financing initially.

In OOS I play about the same role you do. I am developer, researcher and influecer. I understand that you would welcome big corporations to take a part of the costs you have to keep the projects maintained. I am however not a big corporation. If it would help you, I can pay you a few cups of coffee from my personal budget though.

What I can do and I am already doing is to bring more people to you, potentially working in the big corporations. In numbers, I have spreaded the word of your repos, mainly for https://github.com/ergebnis/composer-normalize and newly for this one, to thousands of people, and even added these to popular repos like PrestaShop, Roundcube, atk4, ... Besides my direct contributions, this is a support I do for you and will happily continue to do to participate on your bills and projects this way.

[localheinz]

Well then, let's get it merged, @mvorisek!

[localheinz]

Thank you, @mvorisek!

[mvorisek]

Thank you ❤