search

atsamd-rs / atsamd

Target atsamd microcontrollers using Rust
https://matrix.to/#/#atsamd-rs:matrix.org
Apache License 2.0
557 stars 199 forks source link

Ship a 1.0 release of atsamd-hal #334

Open jessebraham opened 3 years ago

jessebraham commented 3 years ago

This is still a work in progress.

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

Currently blocked by:

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

bradleyharden commented 3 years ago

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 commented 3 years ago

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 notifications@github.com 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 https://github.com/atsamd-rs/atsamd/issues/334#issuecomment-778664741, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5YNWVT4SDFSA54A5YJFKTS63FYBANCNFSM4UBM2G3Q .

Sympatron commented 3 years ago

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 commented 3 years ago

I think #426 should be in here for 1.0