@luislard is there any reason why this is in draft, are you planning more work before you consider it mergeable?

@luislard is there any reason why this is in draft, are you planning more work before you consider it mergeable?

Yes,

1. I didn't know if the maintainers want to go this way.

2. I would suggest to create a new major version branch to merge this branch to. Maybe a 2.x branch

After having a 2.x branch I will switch the target and move from the draft state.

@luislard I think this is simpler enough to be managed on single branch.

We can just release v2 with the changes, and that's it.

This could be a breaking change for people who require the package via dev-master, but there was backward compatibility promise on the master branch, so nobody should be done this and expect backward compatibility.

Also this package has 304 downloads in 7 years, and I'm sure I'm responsible myself for a good potion of those, so let's not make things more complicated they need to be.

The Pr looks fine to me, but we probably needs some test to make sure the code actuall work with the whole matrix of dependencies we are commiting to.

That means PHP 8.0 - 8.3 and Composer 2.0 - 2.6, those are 24 combinations if I'm not mistaken, and we should have basic tests checking for all of them.