Giters

rust-embedded / cortex-m-rt

Minimal startup / runtime for Cortex-M microcontrollers

Home Page:https://rust-embedded.github.io/cortex-m-rt/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Use the semver trick?

Sh3Rm4n opened this issue · comments

commented

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.

commented

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...

commented

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

commented

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.