You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should just have one feature unstable. I thought about a feature per driver/module but in reality enabling all or just a few won't make a difference to the end user, if we make a breaking change to an unstable API it will only affect users who are actively using that API, not just because its available.
How we implement unstable is being tracked here: #2498
The text was updated successfully, but these errors were encountered:
We need to mark APIs we're not stabilizing as such. These are all APIs except following:
esp_hal::init
esp_hal::Config
CpuClock
, everything else should be unstableclocks
CpuClock
should only be exposed as stable, but with no variants, only thedefault()
andmax()
methods should be stabilized.peripheral
- Evaluate thePeripheral
andPeripheral
ref module #2661peripherals
- Ensure the PAC crates are never exposed publicly #2525prelude
- [RFC] Do we need a prelude? #2660gpio
- Stable driver analysis: GPIO #2492uart
- Stable driver analysis: UART #2495spi::master::Spi
- Stable driver analysis: SPI master #2494i2c::master::I2c
- Stable driver analysis: I2C master #2493We should just have one feature
unstable
. I thought about a feature per driver/module but in reality enabling all or just a few won't make a difference to the end user, if we make a breaking change to an unstable API it will only affect users who are actively using that API, not just because its available.How we implement unstable is being tracked here: #2498
The text was updated successfully, but these errors were encountered: