-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v0.13 Roadmap #448
Comments
I would say we should go with a deprecation warning before removing v1. |
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. |
Should we include #450 as well? |
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. |
@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! |
How much time do you have? I feel like an enormous amount has happened. Good idea |
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 |
@jbeaurivage, where does this stand? It looks like it's mostly ready. But it also looks like all the BSPs still point to Also, I'd like to propose two additional deprecations:
|
@bradleyharden: it is finished, unless you have more suggestions. I just pushed the deprecation of |
@bradleyharden, I think this is ready to go. CI will fail until |
Closed with #462 |
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 SERCOMPad
API (Refactor SERCOM pads, add documentation and port feather_m0 to gpio::v2 #434)Removesercom::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
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:
Related issues
The text was updated successfully, but these errors were encountered: