Handle versioned interfaces about spin

[lann]

I predict this is going to be a problem very soon after open sourcing.

[radu-matei]

Why soon after open sourcing?
I was thinking we needed to fix this as we approach the first stable release, at v1.
Then, when we introduce v2, we'd need to make sure we can safely execute v1 components.

[lann]

We can't make any backward-incompatible changes to an interface (including things as simple as reordering struct fields I think) without running into this right?

[radu-matei]

That is correct, if we make any changes to anything in the interface, all components targeting it would have to be rebuilt.

The main question here is less related avoiding breaking changes this early on, and more to making sure the configuration is structured such that we can introduce the versioned objects at some point.

One option this could go is: at some point we decide on V1 for the current interfaces, and tag the current corresponding executors as V1 as well.
If we want to make any backwards incompatible change, we start V2 for both interfaces and executors, and, if everything went as expected, we could run V1 and V2 components side-by-side.

(one big thing here is that even for V1 executors, we will need to keep the Wasmtime versions in sync for us to be able to run them in the same Cargo project.)

Is this aligned with what you were thinking about?

[lann]

Yeah, I think this plays into a larger theme of stability guarantees. We should be explicit about how (un)stable these interfaces are.

[itowlson]

Removed "for entry points" from title as I envisage it being an issue for outbound interfaces too!