fix: pin php-http/discovery to < 1.15

[stayallive]

From #1462, we decided it might be better to pin the dependency to a non-problematic version for the time being (php-http/discovery#213).

[X-Coder264]

I wouldn't do that, the only actual issue that 1.15 caused already has a bug fix PR opened and is probably gonna be merged/tagged soon -> php-http/discovery#214

[cleptric]

I don't want to prompt our users with php-http/discovery contains a Composer plugin which is currently not in your allow-plugins config when they update their dependencies. Before we ship #1459, there are currently no benefits of using 1.15.

[nicolas-grekas]

I wouldn't have merged this because it's not sentry's responsibility to force an upper bound to another dep.
But anyway, #1459 should be the next step so 🤷
See php-http/discovery#213 (comment) also

[HypeMC]

Won't this block any project using sentry from using v1.15. Sentry is not the only library that uses php-http/discovery, there might be libraries/projects that can already benefit from the new version, but now they're blocked from doing so.

[mfb]

A new plugin feels like a BC break for library maintainers such as myself. E.g., my library depends on sentry/sdk and is in turn used by thousands of actual end-user projects. I obviously don't have a way to enable/disable plugins in my end users' projects. I could update my README and roll a new release to attempt to educate users about how they suddenly need to enable or disable the new plugin, but that still feels like a BC break.

[nicolas-grekas]

@mfb please have a look at the discussion in php-http/discovery#213 it might give a few useful hint about the topic.

[mfb]

@nicolas-grekas I've read that but seems like the takeaway is simply that the plugin needs to be disabled or enabled. And as a library maintainer, I cannot disable or enable the plugin, all I can do is ask the end users to disable or enable the plugin for their projects. I'm happy to add that instruction to my README, but I also wanted to point out that ideally, users wouldn't see such breakage happen without a major release somewhere in the chain of dependencies.