Skip to content
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

Closed
thejpster opened this issue Jan 7, 2020 · 73 comments
Closed

Ship a 1.0 release #177

thejpster opened this issue Jan 7, 2020 · 73 comments
Milestone

Comments

@thejpster
Copy link
Contributor

thejpster commented Jan 7, 2020

Part of rust-embedded/wg#383

Settled blockers:

Open blockers:

Feel free to nominate issues also by commenting below

@jamesmunns
Copy link
Member

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 :)

bors bot added a commit that referenced this issue Mar 16, 2020
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>
@eldruin
Copy link
Member

eldruin commented May 6, 2020

I believe the only unresolved issue as of the list above is #172
I would also add the dependency on rust-embedded/nb#20
Then we need to think about the dev-dependencies which are at the moment stm32f3 and futures. I guess specially these will hold us back for a while.

@Disasm
Copy link
Member

Disasm commented Jun 10, 2020

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 v2.0.0.

@therealprof
Copy link
Contributor

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 async-std vs std, i.e. have the async traits in a separate crate async-embedded-hal which would allow crates to move indepedently and express more clearly what is supported where.

@ryankurte
Copy link
Contributor

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 nb or poll traits as we have now with the blocking default methods, so we have one source of truth for integration, simplify the job of hal implementers, and you'll always have access to both. Or if these introduce fundamentally incompatible requirements and must be managed separately. this, however, is not something we can conclusively tell afaik.

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)

@hannobraun
Copy link
Member

I'd like to nominate #249 as a blocker for the 1.0 release.

@hannobraun
Copy link
Member

@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 PinState.

@eldruin
Copy link
Member

eldruin commented Nov 10, 2023

Those mean porting a variety of drivers and MCU and linux HAL implementations to the -rc.1 version and reporting if there are any problems or not.
That is where I see help needed the most, since it is based on community work.

@pbert519
Copy link

What exactly means a variety of drivers and HAL implementations?
Is it a number? A percentage? A list of important crates? A feeling?
The goal is not measurable unless there is some kind of definition.

@Finomnis
Copy link

I would in general be interested in starting a migration for imxrt-hal. The important open question to me is: How stable is the embedded-hal 1.0 API already? How much can we expect it to change? Is it intended to stay as-is and only change if we discover problems? Or are there still open design decisions?

@Dirbaio
Copy link
Member

Dirbaio commented Nov 10, 2023

1.0-rc1 should be identical to the final 1.0, unless some problem is discovered.

@tgross35
Copy link

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

@tgross35
Copy link

esp-hal already supports this rc esp-rs/esp-hal#926

@ithinuel
Copy link
Member

https://github.com/rp-rs/rp-hal does too :)

@tgross35
Copy link

Just searching around https://grep.app/search?q=embedded-hal%5Cw%2A%20%3D.%2A1%5C.0.%2A%28rc%7Calpha%29&regexp=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.

@rursprung
Copy link
Contributor

thanks a lot for your list, @tgross35 !

your regex is missing some dependencies which are written in a different format. e.g. stm32f4xx-hal supports embedded-hal v1.0.0-alpha.11 (and there's an issue for the RC upgrade: stm32-rs/stm32f4xx-hal#686), so a major stm32 HAL is already supporting it, which should be a good sign 🙂

@adamgreig
Copy link
Member

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!

@madsmtm
Copy link

madsmtm commented Nov 21, 2023

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 embedded-hal crate, right? E.g. the release of v1.0 of embedded-hal-async should probably wait until the async trait functionality reaches stable Rust - at which point its functionality will probably just be included in embedded-hal itself.

Speaking of async, we should probably decide at least a rough plan for how that integration will look like, given that async fn in traits will be stable in 1.75.

@adamgreig
Copy link
Member

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.

@Finomnis
Copy link

I wouldn't be against it :) Although I don't think the plan to do so would interfere with an eh 1.0 release.

@Dirbaio
Copy link
Member

Dirbaio commented Nov 25, 2023

this was discussed when we did the split initially, the decision was to leave them split after 1.0.

@Dirbaio
Copy link
Member

Dirbaio commented Dec 14, 2023

📣 we just released v1.0.0-rc.3 with a small GPIO trait change (require &mut self in all methods, previously InputPin and StatefulOutputPin required only &self).

We'd appreciate it if you could do another round of testing. Change looks small but InputPin is a quite foundational trait, and the change might have unintended consequences in type inference / method resolution, we'd love to hear if it's causing issues for you.

@eldruin
Copy link
Member

eldruin commented Dec 27, 2023

I have updated the list of pending issues here. @Dirbaio could you have a look?

@Florob
Copy link

Florob commented Dec 27, 2023

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 flush()?

@Dirbaio
Copy link
Member

Dirbaio commented Dec 27, 2023

thanks @eldruin @Florob for bringing these up, I've sent a few PRs and believe they're all cleared now.

@Dirbaio
Copy link
Member

Dirbaio commented Dec 28, 2023

No release today, it's going to be delayed a bit due to being blocked on #547

@eldruin
Copy link
Member

eldruin commented Jan 9, 2024

embedded-hal and embedded-hal-async 1.0.0 have now been released.
Thank you so much to everyone that was worked and helped through all this time to make this a reality.
🎉

@eldruin eldruin closed this as completed Jan 9, 2024
@eldruin eldruin unpinned this issue Jan 9, 2024
@dbrgn
Copy link
Contributor

dbrgn commented Jan 10, 2024

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! 🦀

@hansfbaier
Copy link

Awesome!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests