Investigate WIT interface version upgrades
How do we handle backward-compatible (i.e. adding a function) WIT interface upgrades?
This is a consideration for adding date/time types to rdbms-types which it would be good to progress for Spin 3.
I'm not sure if the package/world revs to add wasi:config and wasi:keyvalue also fall under this, but if not, well, we need to figure out how to deliver those too... grin
For the upcoming Spin 3.0 release anticipated this week, do I have this right?
rdbms-types: postgres added in https://github.com/fermyon/spin/issues/2870; mysql TODO (post-3.0?)wasi:keyvalue: 0.2.0-draft2 support landed in 3.0 (https://github.com/fermyon/spin/issues/2873)wasi:config: ?
In any case, do we want to keep this issue open to track other WIT interface version upgrades in the future? Or close with an accurate summary of what landed in 3.0 at this time?
wasi-config is merged
I think this issue is asking for a general principle / documented cookbook rather than being closable by specific WITs though?
Might be worthwhile to investigate how the wstd/wasi-crates attempt to address this.
@lann What would allow us to close this issue? It's tagged 3.0, which I think was released by the ancient Assyrians: do our current (post-3.0) informal practices suffice, or is there something more you're after?
This should help address it: https://github.com/WebAssembly/component-model/pull/536