v0.9.0 Release Tracking Issue

[jamesmunns]

We're probably due up for a new release, as the Instance changes have not been released yet.

CC #122.

Are there any other changes we would like to land before the next release?

Must do:

• Update relevant version numbers
• Update BSP crates

Could do:

• Rename nrf52-hal/nrf52-hal-common, maybe to nrf-hal and nrf-hal-common, CC Consider renaming repo name #113
• Land Don't take access to the nvic, no longer necessary #123 (breaking change)
• Land Consistently check slices to prevent odd EasyDMA errors #124 (not breaking change)
• Land Added interrupt driven UARTE (open for feedback, do not merge yet) #102 (needs feedback from @korken89)
• Update PAC crates (not breaking change, probably)
  • 52810
  • 52832 (see This regenerates the -pac crate with svd2rust 0.16.1 nrf52832-pac#14)
  • 52840
  • 9160

Do we have any other (potentially breaking) changes we would like to land soon?

CC @nrf-rs/nrf52 crew

I'd suggest we aim for a release next weekend (I have some time on a train next Saturday, so I'd be up to take the lead on this).

[hannobraun]

• I think if we're already taking the effort to do a release, we can do the rename too (not volunteering, so feel free to disregard).
• Don't take access to the nvic, no longer necessary #123 should land (after discussion). It's a small change.
• Consistently check slices to prevent odd EasyDMA errors #124 is merged.
• I don't think we should wait for Added interrupt driven UARTE (open for feedback, do not merge yet) #102. If it gets in before the release that's a bonus, but we shouldn't delay. A release is overdue.
• It would be great if PACs could get updated.

This is a bit off-topic, but I'm here already, and we're talking about PACs: We should consider merging the PACs into one crate (not just one repository), like stm32-rs is doing. That would be simpler to maintain and I don't see any drawbacks. It would have the additional advantage that we could easily merge the HALs into one crate, which I think we should do (with multiple PACs, the single HAL crate would need multiple rt features, like here).

Not saying we need to do it before the release, but if we're doing a release anyway and everyone happens to agree instantly, then why not. If not, don't worry. I'll prepare a proper proposal at some unspecified point in the future.

[korken89]

On #102, Per and I are going to have a sit this week to fix the outstanding issues with it.
Hopefully it will be ready for merge then, but I do not see it as critical for 0.9.0, it can be in 0.9.1.

[JJJollyjim]

I have submitted regens to the 3 remaining PACs, though I did that before reading you talking about merging them :)

Either way, I will have a go at updating the HAL to use these.

[hannobraun]

I have submitted regens to the 3 remaining PACs, though I did that before reading you talking about merging them :)

I think what you did was definitely worthwhile! I don't think merging the PACs will happen before the next release, if it happens at all.

[thejpster]

We should talk to @themadinventor about moving themadinventor/nrf91 to nrf-rs/nrf9160-pac, and republishing to crates.io under the new name.

[nikyta777]

пидарас я тебя ебну

[dbrgn]

We're probably due up for a new release, as the Instance changes have not been released yet.

Digital v2 trait impls are also missing 🙂

Do we need to do all open issues as part of 0.9, or could some of them be postponed to 0.10?

[Yatekii]

I guess some could be postponed, but did we have so many changes yet? Also there is so much open stuff :/

[thejpster]

Can we get this pushed out the door? Release early, release often and all that. Publishing the actinius-icarus board support crate is blocked on this release.

[jonas-schievink]

Yup, let's do it. Just let me fix the soundness bug in #123 before.

[thejpster]

Is this gated on nRF51 support?

[fmckeogh]

There's 3 modules left to do and while I have been testing as I go, it will definitely need review and testing from someone else. I'm not sure how fast this process can/should be so skipping nRF51 support for 9.0.0 might be a good idea.

AFAIK adding the nrf51-hal crate doesn't affect the other HALs so could be released later without bumping the other versions? Or is that bad practice?

[thejpster]

I think #123 is done via #135?

[Yatekii]

I think #123 is done via #135?

yes :)