Relax dependency version constraints for improved compatibility

[JoshuaBatty]

Description

This PR relaxes version constraints across the crate's dependencies.

Changes:

• Updated version constraints for all dependencies to use minor version specifications instead of patch versions
• Bumped crate version to 0.33.1

Why this is needed:

The exact version specifications were causing dependency resolution conflicts when bevy_egui was used in projects that also depend on other crates using different patch versions of these dependencies. By relaxing the constraints to minor version level, we maintain compatibility while allowing Cargo to resolve to the most appropriate patch version.

[vladbat00]

Hi! Thanks for the PR.

Is there any specific crate that was causing issues for you? I'd prefer being a bit more conservative with this change, so that we don't accidentally allow too old versions of dependencies, where the crate doesn't actually compile.

An example of such dependency would be wasm-bindgen, we definitely use some features that aren't available in 0.2.0. And I've just realized that we already depend on some API that was only introduced 0.2.93 (stabilized clipboard), so 0.2.84 (in the current Cargo.toml) is actually too loose. 🙃

I don't particularly mind changes such as 0.15.0 to 0.15, but they don't actually have any effect on version resolution so I'd prefer to keep the diff shorter.

I'm still open to merging this, but I'd suggest we limit this PR just to the crates that were causing resolution conflicts for you.

[djeedai]

@vladbat00 I agree in principle, except you got caught like me, version = "0.15.0" does not pin the version to .0, and doesn't prevent cargo from upgrading to e.g. 0.15.1. To that respect it's exactly the same as version = "0.15". You'd want to use =0.15.0 to pin to a .0 patch release.

[vladbat00]

No, my comment wasn't implying that :)
I know that 0.15.0 equals ^0.15.0, in my previous comment I was merely saying that 0.15 equals 0.15.0 (which means ^0.15.0). That's why I don't see a point in removing patch versions from the dependency declarations.

We aren't pinning any crates to a specific version, with an assumption that all our dependencies follow semver.

Unfortunately, I don't know which specific crate was causing issues for @JoshuaBatty. I don't want to merge this PR as is, so I'm waiting for an answer to make a more precise fix.
Like I mentioned, we shouldn't relax versions too much either (e.g. at least for wasm-bindgen that would be incorrect).

[djeedai]

I see, thanks for the explanation! Indeed removing .0 wouldn't change any dependency resolution.

[vladbat00]

I'll close the PR since it's been stale for a while. But feel free to open a new one if the issue still persists.