Run tests on PHP 8.5 too

[spaze]

Also update the PHP supported versions in the README to reflect the tests.

[spaze]

Should I also submit a similar PRs to the 9.x and 10.x branches, or are you going to rebase those branches on 8.x? I see that 9.x is based off 8.x, but 10.x is not.

[williamdes]

Hi @antonioribeiro
What do you think about recent PRs ?
I am looking into the state of this project to know if my efforts to package it into Debian will have some future. That means I will do more maintenance PRs too.

[antonioribeiro]

@spaze, we can probably merge this into 8.x, but 9.x has a different github actions workflow structure and is already being tested on PHP 8.5 since Sep 2025.

But 10.x is another beast, there's still a lot of work to be done on it and it will probably be based on the current 9.x.

Hey @williamdes, I love and I keep working on PRs, as much as I can, and I would probably love to see it landing on Debian, but now I'm also really curious to understand how/where... 🤔

[williamdes]

Hey @williamdes, I love and I keep working on PRs, as much as I can, and I would probably love to see it landing on Debian, but now I'm also really curious to understand how/where... 🤔

Sure, let me explain the Debian process and way of things.

First there is the upstream version (this repository), then comes the vendor repository.
Basically we merge your upstream version (download button on GitHub or git clone) into the Debian branch.
The Debian branch has one more folder than upstream /debian.

In this folder is all the packaging configuration:

• debian/control -> Describes the package and the packaging dependencies (Example: You will see that it says it needs phpunit)
• debian/watch -> Explains to uscan where to find upstream versions and check for new ones Example
• debian/rules -> Defines how to build the package, and how to run tests Example
• debian/install -> Where to install the files Example

There is many more files but you can build a simple and working example with only some files above and a bit more.

So you can now start to understand that the upstream code is tested with what we want in Debian. That means that the current version of phpunit: https://tracker.debian.org/pkg/phpunit is used to test all packages in Debian.

If you want to change that, it makes an enormous transition and a lot of work: https://bugs.debian.org/1084894

In an ideal world I open PRs to upstreams so they are ready for the new phpunit version.
When they do not want to comply with our problems, there comes debian/patches/file-name.patch.
You can patch the upstream code: Example

Sometimes you do not want to send your patch to upstream, so you indicate it in the patch file: Example
You can learn more about patch metadata here: https://dep-team.pages.debian.net/deps/dep3/

But when a new upstream version is imported you need to rebase all the patches, welcome in hell.
So it is best to have upstream to merge your work and release it. Making you have less things to look after.

You can find quite some package examples in: https://salsa.debian.org/explore/projects/topics/wdes-packaging-team

Feel free to ask questions about this, there is much more to say to that should explain a bit about phpunit.

PS: Debian has one version of PHP available and everything must comply with it. So you can say whatever you want in composer.json it will not be respected. This is a bit frustrating for everyone. But most of the time the code just runs fine with newer PHP versions. Tests (when packaging people run them) ensure new PHP versions do not break a project.