@lulf If you can look at PR #78

@alexmoon did ask me to move the nrf-802154* crates into a separate repo.

My one concern with that is that if the nrfxlib and nrfx are updated in nrf-mpsl*, I must know that so that I use matching versions of those two in my nrf-802154 driver crates. Or else, if I don't have to do that, I would be enlightened to know if and why an nrf-802154 driver from - say - nrfxlib X.Y.Z can work with mpls from nrfxlib A.B.C and even if it does, does the whole stuff follow any semver guarantees on the C lib level.

Or the TL;DR is: is it really OK (in future) to bump the nrfxlib to a newer version without bumping the minor versions of the nrf-mpsl* crates and possibly nrf-sdc* crates? And what would the bump rule look like (semver)? I.e. bumping from 3.0.0 to 3.1.1 is "OK" and would work with a "3.0.0" nrf-802154? But then bumping to e.g. "4.0.0" means you will bump the minor v. of nrf-mpsl* and transitively - to nrf-sdc*?

@lulf If you can look at PR #78

@alexmoon did ask me to move the nrf-802154* crates into a separate repo.

My one concern with that is that if the nrfxlib and nrfx are updated in nrf-mpsl*, I must know that so that I use matching versions of those two in my nrf-802154 driver crates. Or else, if I don't have to do that, I would be enlightened to know if and why an nrf-802154 driver from - say - nrfxlib X.Y.Z can work with mpls from nrfxlib A.B.C and even if it does, does the whole stuff follow any semver guarantees on the C lib level.

Or the TL;DR is: is it really OK (in future) to bump the nrfxlib to a newer version without bumping the minor versions of the nrf-mpsl* crates and possibly nrf-sdc* crates? And what would the bump rule look like (semver)? I.e. bumping from 3.0.0 to 3.1.1 is "OK" and would work with a "3.0.0" nrf-802154? But then bumping to e.g. "4.0.0" means you will bump the minor v. of nrf-mpsl* and transitively - to nrf-sdc*?

I think that for nrf-802154 you should use the same version nrfxlib as nrf-mpsl. I think any update of nrfxlib or nrfx in this repo should bump the major version of nrf-sdc (well, minor for now since it's pre 1.0).

Then for nrf-802154 on main you probably want to pin it to some nrf-sdc git rev and/or release. Then the 'overhead' is really just to make sure that when you update nrf-sdc/nrf-mpsl, you update the gitsubmodule in nrf-802154 to match?

I think that for nrf-802154 you should use the same version nrfxlib as nrf-mpsl. I think any update of nrfxlib or nrfx in this repo should bump the major version of nrf-sdc (well, minor for now since it's pre 1.0).

... and nrf-mpsl*. nrf-802154 does not care about nrf-sdc* actually.

Then for nrf-802154 on main you probably want to pin it to some nrf-sdc git rev and/or release. Then the 'overhead' is really just to make sure that when you update nrf-sdc/nrf-mpsl, you update the gitsubmodule in nrf-802154 to match?

That was the plan. So in theory, if nrf-802154 was already available (and published on crates.io) your PR would've included a version bump on the nrf-mpsl* crates and transitively of nrf-sdc*?

My only question is: does an nrfx update from 3.0.0 to 3.1.1 (as you did now) would really require a minor v bump of the crates?

If Nordic follows semver, perhaps not? But then perhaps their semver is only to the "outside world", but maybe there is no guarantee, that a "3.0.0" nrf-802154 would work on top of a "3.1.1" mpsl?

I think that for nrf-802154 you should use the same version nrfxlib as nrf-mpsl. I think any update of nrfxlib or nrfx in this repo should bump the major version of nrf-sdc (well, minor for now since it's pre 1.0).

... and nrf-mpsl*. nrf-802154 does not care about nrf-sdc* actually.

Then for nrf-802154 on main you probably want to pin it to some nrf-sdc git rev and/or release. Then the 'overhead' is really just to make sure that when you update nrf-sdc/nrf-mpsl, you update the gitsubmodule in nrf-802154 to match?

That was the plan. So in theory, if nrf-802154 was already available (and published on crates.io) your PR would've included a version bump on the nrf-mpsl* crates and transitively of nrf-sdc*?

I usually bump/check if version bump is needed during preparation for a release, not during the update itself, because it takes some time to analyze whether or not a major/minor/micro bump is needed, and there can be more changes before the release that might cause a bump.

My only question is: does an nrfx update from 3.0.0 to 3.1.1 (as you did now) would really require a minor v bump of the crates?

They generally break/remove APIs in minor versions, not sure about functionality. Think maybe major versions signals BLE version support change as well. But I'm guessing.

If Nordic follows semver, perhaps not? But then perhaps their semver is only to the "outside world", but maybe there is no guarantee, that a "3.0.0" nrf-802154 would work on top of a "3.1.1" mpsl?

I'm not sure if they follow semver or not, so might be safer to assume not.

I'm not sure if they follow semver or not, so might be safer to assume not.

Fair enough. I'll close #78 shortly and move it here. Crate names' reservation on crates.io also in progress.