If we speak about theory, the variables that we must consider for the matrix are:

• version of Symfony
• version of the dependencies (lowest and highest)
• version of PHP
• OS

Exploding such matrix into builds will generate a lot of them, that's a fact, but it's also the correct way to ensure that everything works well in all scenarios. Any other solution involving less builds is likely better for resources and time, but it will be also more error-prone. I've seen other repos where they have a lot of checks, and I don't think it would be a problem for us to do the same in terms of numbers, and our CI is anyway fast enough to not take ages to complete

Due to the Symfony BC promise, it should be superfluous to test all those versions though.
Also, I'm not sure about OS, since we shouldn't have any OS-dependent handling in this bundle, whereas in the base SDK we have something more low-level that could, and in fact we test it.

@Jean85
I think it's important to check now (Symfony 4.4.* / Symfony 5.0. *) together with PHP versions 7.4 and 8.0. in the future the most popular number of projects.

@Yozhef still, the BC promise protects us in that regard: 5.0 is the same as 4.4 without deprecation, and any 5.x will still be compatible with 5.0.

So I would test against:

• 3.4
• 4.4
• 5.x
• prefer-lowest (which is forcibly 3.4)

This would mean 4 deps versions + 4 PHP versions already (7.2 -> 8.0) or 8 if you count OS variation, for a total of 12 + static analysis... If you add any version in between we're going over 20-30!

@Jean85 I think that's enough, but ready to listen to what you suggest to change? Now we have:
Symfony 5.0.* PHP 8.0
Symfony 5.0.* PHP 7.4
Symfony 4.4.* PHP 8.0
Symfony 3.4 PHP 7.2
Symfony 4.4.* PHP 7.4
PHP 8.0
PHP 7.4
PHP 7.3
PHP 7.2
PHP 7.2 - lower

I repeat, testing 5.0 on its own in addition to the latest 5.x doesn't make sense, for the same reason for which we don't test for 4.0.

I would test like this:

• PHP 8.0 (implicitly selects latest SF 5.x)
• PHP 7.4 (implicitly selects latest SF 5.x)
• PHP 7.3 (implicitly selects latest SF 5.x)
• PHP 7.2 (implicitly selects latest SF 5.x)
• PHP 7.4 SF 4.4
• PHP 7.4 SF 3.4
• PHP 7.2 prefer lowest

For a grand total of 7, to double it with OS variation if we want. 14 jobs seems enough to me.

I've re-targeted this to develop to reduce the noise in the diff. It could change again if we merge develop into master due to the preparation of the 4.1 release.

3.4 is giving us some issues: symfony/symfony#40679 has not been backported there since it's not a security fix, the only way I see to fix this is we should switch to pcov here too.

Also, we need to exclude 8.0 + 3.4 because there's no compatible set of components: https://github.com/getsentry/sentry-symfony/pull/410/checks?check_run_id=2336880519