Major version updates on dependency major version updates?

[daboross]

Hi! Love the work this is doing.

Would you consider bumping the major version of this plugin, though, when you upgrade major versions of dependencies? By that I mean the second number; for 0.x.y pre-1.0 versions, cargo treats x as major and y as minor.

The reasoning for this is that Cargo treats minor versions as practically identical. cargo update will update things with the assumption that version 0.1.4 is backwards compatible with 0.1.3. But upgrading bevy in this project is a breaking change, since bevy_prototype_lyon returns types from bevy in its interface.

To put it more concretely, if someone depends on bevy = "0.3.0" and bevy_prototype_lyon = "0.1.3", then upgrading to bevy_prototype_lyon 0.1.4 will break their build. They'll get an error "expected bevy (0.3.0)::SpriteComponents, found bevy (0.4.0)::SpriteBundle. Breaking changes are fine, but they should be denoted by major version updates so that cargo can treat them appropriately (and not automatically apply them).

I don't think this is too big of a deal since everything's in alpha phase right now, but it would still be nice! If you could either yank 0.1.4/0.1.5 and publish as 0.2.0, or just bump to 0.2.0 when upgrading to the next bevy version, that would be awesome. It'd let cargo's versioning work for users, and keep the semantic versioning accurate.

Regardless, thanks for making this! Glad to have it here :)

[Nilirad]

Hi! Thanks for using this tool!
I agree with you, especially if that helps people to avoid breaking changes.

I'll keep that in mind for the next updates.