This is a BC break. Let's target the 6.0 branch instead.

I'm totally fine with targeting 6.0 instead, but I don't believe this should result in a BC break. Narrowing return types (in this case, going from implicit mixed to explicit bool) is valid under LSP. I've got library code using both psr/container v1 and v2 in a build matrix with the added return type and it doesn't cause any problems.

Having said that, it's not exactly causing a burning issue for me so I'm fine with waiting for the later version.

Narrowing return types (in this case, going from implicit mixed to explicit bool) is valid under LSP. I've got library code using both psr/container v1 and v2 in a build matrix with the added return type and it doesn't cause any problems.

But it's the opposite for project that use symfony. It's a BC break for all classes that implement the interface.

Having a class without return type can implement the interface in 5.2 and being valid. But if you add a return type, the class will not be valid anymore

Certainly. But this only permits the newer interface, not force it. Any project requiring psr/container:1.x would continue to install that version and work without modification.

I suppose if a project is using Symfony and using their own Container implementation without explicitly requiring psr/container and instead relying on whatever Symfony grabs it could break, but that a) seems unlikely to me and b) that's already a misconfigured project by relying on an indirect dependency.

Again, I won't belabor the point (and you'd certainly know Symfony usage characteristics better than I would), but for any project using this with correctly-declared dependencies, it should be completely safe and not a BC break. I'm under no pressure; just trying to get a line removed from composer outdated :) Up to you!

Certainly. But this only permits the newer interface, not force it. Any project requiring psr/container:1.x would continue to install that version and work without modification.

But this changes our own signature due to allowing the new interface, which is a BC break for our own interface.

I suppose if a project is using Symfony and using their own Container implementation without explicitly requiring psr/container and instead relying on whatever Symfony grabs it could break, but that a) seems unlikely to me and b) that's already a misconfigured project by relying on an indirect dependency.

Projects would be totally fine in requiring the symfony package if what they implement is Symfony's ContainerInterface (which extends the PSR one). The PSR interface is used by the Symfony package, not by the project. But the new major version of psr/container impacts the public API of the Symfony interface.

This should also update other packages requiring service-contracts to allow the new major version of the contracts (as this change will require bumping the major version)

I'm closing because we're not ready yet. There are many more changes we need to do before doing this change (eg prepare a deprecation layer, bump the major version of contracts, etc.)

Is there a timeline on when this dependency can be upgraded?

symfony/service-contracts#1
symfony/contracts#3

End of November.