@carlos-granados while this won't necessarily cover everything (and from experimenting so far it produces a few false positives) I think worth having an extra layer of safety checking in our build as we start working towards 4.x - particularly because I want to start making some backwards-compatible changes in 3.x first to minimise the diff between the two versions.

Wouldn't it be useful to add this dependency as a regular dev dependency, not only in CI? In this way we could run a BC check locally before submitting a PR

The problem is it has quite a few dependencies, including some that it shares with us in stricter versions - e.g. it requires symfony/console:^7.4.0 so it would then constrain the dependencies we can install for all other jobs. There's no shim package available that I can see - their recommended way to avoid that is to run as a docker image but I ran into a couple of issues with that including the check for file/directory ownership in recent git versions, and the docker images also don't appear to be up to date with the latest releases.

It doesn't have to be installed within the project context - once installed it runs against any project directory - so installing it standalone alongside felt like a neater/safer solution.

It's possible to use the same shell steps as the actions job to install it locally in a subdirectory (or any directory) and run it from there assuming the environment has the required tools e.g. git.

I could commit that as a shell script instead of having it just in the actions job, but I actually wonder if it's easier to let people work that out for themselves / tweak it for their preferences rather than trying to have an officially-supported-way of doing it especially given the variations in shells / composer installations / etc?

At some point I might try to look at whether there's anything I can do to get the docker-based flow working neatly (and possibly look at a couple of other issues/enhancements that I've already spotted with it) but I don't want to get too sidetracked from our own 4.x at the moment.

Wouldn't it be useful to add this dependency as a regular dev dependency, not only in CI? In this way we could run a BC check locally before submitting a PR

The problem is it has quite a few dependencies, including some that it shares with us in stricter versions - e.g. it requires symfony/console:^7.4.0 so it would then constrain the dependencies we can install for all other jobs. There's no shim package available that I can see - their recommended way to avoid that is to run as a docker image but I ran into a couple of issues with that including the check for file/directory ownership in recent git versions, and the docker images also don't appear to be up to date with the latest releases.

It doesn't have to be installed within the project context - once installed it runs against any project directory - so installing it standalone alongside felt like a neater/safer solution.

It's possible to use the same shell steps as the actions job to install it locally in a subdirectory (or any directory) and run it from there assuming the environment has the required tools e.g. git.

I could commit that as a shell script instead of having it just in the actions job, but I actually wonder if it's easier to let people work that out for themselves / tweak it for their preferences rather than trying to have an officially-supported-way of doing it especially given the variations in shells / composer installations / etc?

At some point I might try to look at whether there's anything I can do to get the docker-based flow working neatly (and possibly look at a couple of other issues/enhancements that I've already spotted with it) but I don't want to get too sidetracked from our own 4.x at the moment.

Understood. Could we at least add some instructions/pointers explaining how to set this up locally? I myself would like to use this tool

Understood. Could we at least add some instructions/pointers explaining how to set this up locally? I myself would like to use this tool

Good idea - added to the BC section of the contributing docs.