Update rand crate

[PitiBouchon]

Update the rand dependency

Closes #1234
Closes RUST-263

[szokeasaurusrex]

Thanks for the PR. Since this bumps rand from 0.9 to 0.10, which may include breaking changes, I’d like to have an issue first explaining why the upgrade is needed and what impact we should expect.

I’m going to close this for now, but we can revisit it once there’s a clear motivation for the bump.

[PitiBouchon]

@szokeasaurusrex I don't understand why do you need a "clear motivation for the bump" ?

Isn't updating dependencies a good common practice in general and for the ecosystem ?

rand has been updated to > 0.10 since a few months now, updating to 0.10 would not be quick/instant risking a supply chain vulnerability

[szokeasaurusrex]

Keeping dependencies reasonably up to date can be good practice, but dependency updates are not risk-free, especially for semver-major upgrades.

Sentry’s development philosophy says that dependencies come with a cost, and specifically: “we believe that our default position about a dependency should be not to upgrade.” It also says upgrades can be warranted, but that they come at a cost and need to be considered.

For rand 0.9 to 0.10, I need a project-specific reason to take on that review cost. Please open an issue explaining the motivation for the bump and any expected impact or migration concerns, and we can revisit it from there.

[roblabla]

Not upgrading dependencies can make sense in the context of applications - where there is a real cost to upgrade, with little benefit on its own. But in libraries, choosing not to upgrade imposes a permanent tax on your downstream users. If every single library takes your approach, we'll end up in a position where we'll have dozens of versions of all the fundamental crates (rand, windows-sys, etc...), which is just unsustainable.

We're (I work with @PitiBouchon) looking to reduce the amount of duplicate crates in our codebase to try and combat this rise in compile time. I hope you will reconsider your position.

[szokeasaurusrex]

We're (I work with @PitiBouchon) looking to reduce the amount of duplicate crates in our codebase to try and combat this rise in compile time.

Thanks for clarifying, that's a totally sensible reason and I'm happy to reopen this PR in light of that