Ship a 1.0 release of atsamd-hal

[jessebraham]

This is still a work in progress.

Milestone:
https://github.com/atsamd-rs/atsamd/milestone/1

Currently blocked by:

• Update embedded-hal dependency to 1.0 (Update embedded-hal dependency to 1.0 #332)
• Use embedded-time (Use embedded-time #333)
• Refactor UART implementation (Refactor UART implementation #329)
• Implement relevant RTC modes for all build targets (Implement relevant RTC modes for all build targets #44)

If you feel any additional issues should be addressed please comment below or let us know in Matrix.

[bradleyharden]

What's the position on SemVer and incrementing the major version?

I ask, because 1.0 implies API stability. But, as mentioned a few times, many of the APIs are limited to a small subset of the given peripheral's functionality. I'm not surprised or upset by that. Implementing a complete driver is a lot of work. But if someone wants to rewrite a module to be more configurable, that might need to break the existing API.

In that case, would we take the v1/v2 approach, like the gpio module? Then we would drop support for v1 in the next major revision? Or would we just increment the major version immediately and not worry about maintaining support for the old API?

[TDHolmes]

I’ve also had this thought. Do we really want the burden of SemVer 1.0? Are we really there yet with our existing APIs? E.g., We’re only starting to think about DMA and haven’t integrated it into any of the peripherals yet. The integration would likely break the API

…

On Sat, Feb 13, 2021 at 11:16 AM Bradley Harden ***@***.***> wrote: What's the position on SemVer and incrementing the major version? I ask, because 1.0 implies API stability. But, as mentioned a few times, many of the APIs are limited to a small subset of the given peripheral's functionality. I'm not surprised or upset by that. Implementing a complete driver is a lot of work. But if someone wants to rewrite a module to be more configurable, that might need to break the existing API. In that case, would we take the v1/v2 approach, like the gpio module? Then we would drop support for v1 in the next major revision? Or would we just increment the major version immediately and not worry about maintaining support for the old API? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#334 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5YNWVT4SDFSA54A5YJFKTS63FYBANCNFSM4UBM2G3Q> .

[Sympatron]

I think the API is currently not stable enough. I suppose we want to update all modules to use gpio v2 eventually and I would personally not go 1.0 until that is done. I would even deprecate v1 (or even remove it) and set v2 as the default before switching to 1.0. This shouldn't be rushed IMO, because it doesn't need to. Once you declare the API stable with 1.0 you have to be much more careful when you want to change/improve things.

[jacobrosenthal]

I think #426 should be in here for 1.0