search

rust-embedded / cortex-m-rt

Minimal startup / runtime for Cortex-M microcontrollers
https://rust-embedded.github.io/cortex-m-rt/
Apache License 2.0
359 stars 85 forks source link

Use the semver trick? #333

Closed Sh3Rm4n closed 3 years ago

Sh3Rm4n commented 3 years ago

As version v0.7.0 is now released, the rust-embedded will slowly transition to using it.

Because this is a minor bump version and therefor incompatible with v0.6.x these two dependencies can not co-exist in a dependency tree. It would take a major effort to update to v0.7 as many crates in the eco-system have to coordinate this effort.

It might however be smoother to introduce the semver-trick and release version v0.6.16 with all compatible types?

Is that even a viable option? I haven't really looked into the technical details, so I might be missing some important, why the semver-trick wouldn't help in that situation.

adamgreig commented 3 years ago

Are there many crates that depend on cortex-m-rt besides PACs? I had hoped it wouldn't be too bad an upgrade (compared to cortex-m for example). We've had all sorts of annoying problems coordinating the semver-trick releases (and it's a ton of work to go through every public item and work out if it can be safely re-exported from the new version or you have to maintain the old version), so I'd rather avoid it if we can...

I haven't thought about whether it would be viable for c-m-rt. I think basically the only thing other crates rely on is the interrupt macro for PACs, which hasn't changed and so should be easy to re-export. So it's probably possible...

Sh3Rm4n commented 3 years ago

Yeah, maybe this is a non-issue after all. I'll try around a little more ( I mean I haven't really mentioned an example in the OP) and see if that's really a problem and if not I will close this issue.

Thanks for the insight @adamgreig

Sh3Rm4n commented 3 years ago

Are there many crates that depend on cortex-m-rt besides PACs? I had hoped it wouldn't be too bad an upgrade (compared to cortex-m for example).

So I checked the dependency tree of stm32f3xx-hal again and the dependencies which use are panic-probe and defmt-test, firstly which is a special usecase and secondly are optional dependencies. So you are right, that almost nobody besides PACs are using it.

Also solving the possible conflict via PACs and HALs can be done with version = ">=0.6.13, <0.8". This was just not working locally for me, because I forgot to call cargo update before running build again.

So I guess, even though the semver-trick might be possible it is not worth doing it right now, because there is no immediate need for it.