Repository navigation
feat(sdk): gate experimental APIs behind feature - #1395
Conversation
06abe46 to
9b2d1fb
Compare
ed353c2 to
5547bd7
Compare
| script: | | ||
| core.exportVariable('RUSTFLAGS', '-Csymbol-mangling-version=v0'); | ||
| - run: cargo test -- --include-ignored --nocapture | ||
| - run: cargo test --features experimental -- --include-ignored --nocapture |
There was a problem hiding this comment.
Eventually, I want to also run tests w/o experimental just to have extra coverage on that codepath, but want to get CI in a better space before adding another full run blindly. Will be more important if we ever have a behavior addition with experimental instead of just these additive changes.
| #[cfg_attr(not(feature = "experimental"), allow(unreachable_pub))] | ||
| mod worker_lifecycle { |
There was a problem hiding this comment.
Should this be pub or re-exported?
There was a problem hiding this comment.
Gets lost in the diff, but we publicly reexport members it if experimental is enabled. If disabled we just pub(crate) export the members.
There was a problem hiding this comment.
Oh man this is annoying. Maybe we can make a PR there to be able to un-do this?
There was a problem hiding this comment.
I'll look into that
What was changed
experimentalfeature gate.Why?
Make it explicit at a language level what APIs are experimental compared to just a comment. Will allow us to do breaking changes on these APIs with a clear consciousness.
Checklist
Closes N/A
How was this tested:
Existing test suite, ensured we still check that crates compile without feature enabled in CI
Any docs updates needed?
Worth a mention on the Rust docs site since this is a different approach than other SDKs.