-
Notifications
You must be signed in to change notification settings - Fork 202
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
Ship a 1.0 release #177
Comments
Here is a link to the video call discussion had by myself and most of the members of @rust-embedded/hal team. This includes initial decisions made, and justification/reasoning for each point. The next steps for this would be to codify this into an RFC, and get approval for it (though there is already general consensus within the embedded-hal team). by the way, this was the "issue with the list of big topics" we were looking for during the meeting :) |
192: [towards 1.0]: Fallible proven traits r=thejpster a=eldruin Here some work towards 1.0 following #177 (comment). Co-authored-by: Diego Barrios Romero <eldruin@gmail.com>
I believe the only unresolved issue as of the list above is #172 |
This async story began just recently and I do not expect it to end in the coming year. Why should we block on it? We can always add this later. In the worst case, these async traits will be released in embedded-hal |
I also think we should keep async separate because it's a different paradigm and might need require a different approach anyway. I can imagine taking an approach similar to |
i have mixed feelings about async being separate in the long term, but imo it very much depends whether we can find an approach (as is the case for one of the demonstrated ones) that allows everything to be a default impl on top of our base i posed here (#172 (comment)) that if we have a path towards a decision on the nb/futures swap I would be okay to hold, but so long as it's an open / unknown problem I would also prefer to keep moving and accept integrating async may be another breaking change down the line. (i would also very much like to hear the thoughts of @japaric if ya have a moment to look at all of this) |
I'd like to nominate #249 as a blocker for the 1.0 release. |
@rust-embedded/hal Would you consider releasing 1.0-alpha.2? I'm working on a driver that I'd like to release soon, and it would be great if I had access to |
Those mean porting a variety of drivers and MCU and linux HAL implementations to the |
What exactly means a variety of drivers and HAL implementations? |
I would in general be interested in starting a migration for |
1.0-rc1 should be identical to the final 1.0, unless some problem is discovered. |
Is there a target release date? I think crates are probably more likely to start a port in seriousness (and discover bugs) if there is a solid plan to release before the end of the year, barring anything fatal. After all, some crates have had open issues for switching to 1.0 for three years atsamd-rs/atsamd#332 |
esp-hal already supports this rc esp-rs/esp-hal#926 |
https://github.com/rp-rs/rp-hal does too :) |
Just searching around https://grep.app/search?q=embedded-hal%5Cw%2A%20%3D.%2A1%5C.0.%2A%28rc%7Calpha%29®exp=true, it seems like it is actually pretty well used already.
I excluded anything that is still on an alpha or hasn't been updated in a year, which adds 5 or so more crates. That all seems like pretty good coverage the biggest missing ones are atsamd-hal and the stm32 crates (I opened an issue here stm32-rs/stm32f1xx-hal#473 and poked here atsamd-rs/atsamd#332). But embassy covers the STM32 hardware so I wouldn't think this would be too different. It would be good to have a list of specific crates that are need to be tried with the new interface before making it official. |
thanks a lot for your list, @tgross35 ! your regex is missing some dependencies which are written in a different format. e.g. |
After some discussion last week, we now plan to release the final 1.0 version on Dec 28th, assuming no major issues come up before then. Please keep testing the RC in the meantime! |
Hey, I've opened a few issues pertaining to the API surface we're stabilizing: #523, #524, #526, #527 and to a lesser extent #525. I'll volunteer to do the work for each of these, if you think the changes are desired? Also, this is only the v1.0 release of the Speaking of |
Thank you for the review and issues! Not coincidentally, December 28th (the planned e-h 1.0 release) is the day Rust 1.75 is released, and thus the day async traits are in stable Rust, so I think (?) the plan is to release 1.0 of e-h-async at the same time. However, I don't know if there's still a plan to merge it into embedded-hal, though I haven't heard it discussed in some time. |
I wouldn't be against it :) Although I don't think the plan to do so would interfere with an eh 1.0 release. |
this was discussed when we did the split initially, the decision was to leave them split after 1.0. |
📣 we just released v1.0.0-rc.3 with a small GPIO trait change (require We'd appreciate it if you could do another round of testing. Change looks small but |
I have updated the list of pending issues here. @Dirbaio could you have a look? |
I'd like to nominate #455 for the 1.0 release. I.e. specify whether I2C operations can return early like the SPI ones. If so: do we need a |
No release today, it's going to be delayed a bit due to being blocked on #547 |
|
Thanks a lot to all people involved for pushing this forward week after week over the last 6 years! It's been a while 🙂 Embedded Rust has a bright future ahead! 🦀 |
Awesome!!! |
Part of rust-embedded/wg#383
Settled blockers:
WIP: Re-organising repo #169(closed for later consideration)[RFC] Use core language async primitives instead external crates #172[RFC] digital::v3 interface + moving to a single interfaceCapture
trait requires moving/copying channel argument #249Error
types #229 PR: Add error traits for communication interfaces #296Pwm enable and disable methods only work for channels #182 PR: Add methods to enable/disable the entire timer #183IoPin trait not practical to implement with multiple input/output types #340It's not clear whencan::ErrorKind::Acknowledge
should be returned #387SPI implementation doesn't follow embedded-hal requirements for CS linux-embedded-hal#87discussed in WG meetings, we decided we're OK with the solutions in SPI implementation doesn't follow embedded-hal requirements for CS linux-embedded-hal#87 (comment)spi: add settings to embedded-hal-bus SpiDevice impls for CS-to-clock delays. #539docs in spi: documentOperation::DelayNs
is not for CS delays. #559, will add CS delays toembedded-hal-bus
later.spi::Operation::DelayNs
#552Open blockers:
&mut self
inInputPin
andStatefulOutputPin
. #547&mut self
inInputPin
andStatefulOutputPin
" #553 ?Feel free to nominate issues also by commenting below
The text was updated successfully, but these errors were encountered: