v0.13 Roadmap

[jbeaurivage]

It has been quite a while since a release has been rolled out. This issue proposes a roadmap to the next release.

Since there have been many major changes to the HAL recently, I suggest we try to tie off as many features as we can before pulling the trigger to avoid too many breaking changes between future releases.

The reason for suggesting not moving to 1.0.0 is that most people here believe that the API is not mature/stable enough to yet incur that burden.

Please comment if you'd like to see items on/off this list:

To-do list

• New SERCOM Pad API (Refactor SERCOM pads, add documentation and port feather_m0 to gpio::v2 #434)
• Remove sercom::v2::Pad type (Remove the sercom::v2::Pad type and redefine the v2::spi::Pads type #451)
• Add pull resistor support for EIC pins to v2 GPIO API (Add support for pullup/pulldown of EIC pins #444)
• Finalize UART v2 (UART v2 #443)
• Finalize DMAC module (DMAC peripherals #432)
• Come to an agreement on how to support a BSP tier system (please go voice your opinions in Establishing a BSP tier system #433!)

Nice to haves

• New clocking API (Clocking API V2 (for thumbv7em)  #450)
• Get a changelog up and start tagging releases

About v2 modules

It has been mentioned in the Matrix channel that supporting v1 and v2 drivers is going against the intent of semantic versioning. Following that spirit, I'd like to propose retiring the v1 modules where their v2 counterpart is mature enough. I'd like to take suggestions on how this should be done, though. There are a few ways of doing it:

• Mark the v1 modules as deprecated and up for retirement in a subsequent release
• Retire the v1 modules immediately (BSPs will need to be caught up to v2)
• Keep supporting the v1 modules

Related issues

• When is the master usuallly being released to crates.io? #447
• Ship a 1.0 release of atsamd-hal #334
• Establishing a BSP tier system #433

[sajattack]

I would say we should go with a deprecation warning before removing v1.

[ianrrees]

I also like the deprecation warning idea, so long as it doesn't add too much work (read: delay in getting the release out the door), and we follow through with dropping the deprecated things on the following significant release.

Semantic versioning isn't a great fit for this project, because the version applies to the HAL as a whole, but the HAL is a union of several smaller modules for the different peripherals. It might be the case that someone needs a new v2 peripheral feature, but has a dependency on some other peripheral's v1 implementation for instance.

[sajattack]

Should we include #450 as well?
Edit: oop, read too fast.

[bradleyharden]

It's already on the list as a nice-to-have. Were you asking if we should upgrade it? I would probably say no. We haven't released in a while, and that's a big one, with potential to drag out.

My own edit: Responded to the version of your comment in my email, not the edited one.

[jbeaurivage]

@sajattack @twitchyliquid64 @bradleyharden @jessebraham I wasn't here when the 0.12 release went up. It would be great if you guys could come up with the changes that happened since to get a changelog up and running!

[bradleyharden]

How much time do you have? I feel like an enormous amount has happened. Good idea

[jbeaurivage]

No rush, we still have some PRs holding up the release at this time. Maybe in the future, updating the changelog should become a standard part of the PR process too

[bradleyharden]

@jbeaurivage, where does this stand? It looks like it's mostly ready. But it also looks like all the BSPs still point to path = "../../hal". Shouldn't that be removed for Tier 2 boards?

Also, I'd like to propose two additional deprecations:

• Deprecate atsamd_hal::target_device in favor of atsamd_hal::pac
  • target_device is very verbose, and we already have a name for the PAC.
• Deprecate atsamd_hal::hal in favor of atsamd_hal::ehal.
  • Seeing hal::hal in BSP code always had me very confused. I think we should distinguish between embedded-hal and ourselves.

[jbeaurivage]

@bradleyharden: it is finished, unless you have more suggestions. I just pushed the deprecation of hal::hal and hal::target_device. I just wanted to leave pointing all BSPs to atsamd-hal = 0.13 until the last possible second, because CI will start failing as v0.13 is still unpublished. Although I now realize I could have made my life simpler by using the bump BSP and bump crate workflows.

[jbeaurivage]

@bradleyharden, I think this is ready to go. CI will fail until atsamd-hal = 0.13.0 is released to crates.io. The final steps should be carried out by the approver of #462, and are outlined in the todo list of the first comment.

[bradleyharden]

Closed with #462