Should @unstable features be included in stable releases?

[lann]

Context: #143

I think both options here are defensible:

• The @unstable feature is in the source and requires opt-in, so include it in the release
• The @unstable feature is unstable, so omit it from the stable release

I guess its a question of the semantics of @unstable: does it mean "this is part of the current version but not covered by backward-compat rules" or does it mean "this may become part of a future version"?

[lann]

CCing previous participants in discussions about @unstable: @yoshuawuyts @vados-cosmonic @alexcrichton @lukewagner

[thomastaylor312]

Yeah I'm really curious here. My initial gut reaction is that unstable should be included by default as you have purposefully marked it as unstable and that is introspectable by a consumer of the interface. However, I also admit that there has been a lot of debate around the semantics of unstable so curious for opposing opinions to mine

[alexcrichton]

Personally I'd expect these to be included by default in WIT-distribution mechanisms like wkg but still removed-by-default when processing (for example bindings generators). That ensures that everyone's got a consistent view of WIT files no matter the source (e.g. git checkout, wasi.dev, vendored copy, etc).

The theory is that the various bits and pieces of toolilng were all designed to enable this where unstable features show up in text but quickly go away if not otherwise explicitly enabled. That way if you do nothing out-of-your-way then features are all off-by-default.

To me this is similar to how you can view documentation for nightly APIs in doc.rust-lang.org/std where you can see what's coming if there's not something that's already meeting your needs.

[robherley]

So would this be the inverse of what I was experiencing in:

• Incorrect wit for wasi:[email protected] and wasi:[email protected] (unstable features are omitted by default) #143

Where wasmtime had the new bindings generated and the unstable were omitted from the wit I pulled?

[lann]

The suggestion here is to include unstable features in stable releases (still marked as unstable). You would still need to explicitly enable those features where needed but it would make that possible where today it is not.

[alexcrichton]

In theory it should resolve the original issue you were seeing though @robherley where Wasmtime's handling of unstable features is slightly different than other bindings generators because it pushes the feature to a runtime configuration option to provide as opposed to removing it entirely (and the runtime option is off-by-default)

[ricochet]

One challenge with 0.2.x releases is that feature gates were added after 0.2.0. There was a concern of maintaining backwards compatibility for parsers, but I think practically this is a non-issue.

[lann]

Resolved by #147