An "opt into unstable features" feature

[rylev]

The problem

We often have the need to introduce new things into Spin that we know will need time to bake before we're happy with them. However, when releasing new features, those features are effectively "insta-stable" upon their release. This means they only have the time between merge into main until the release to get testing, and this testing can only be done by users of the canary release or those who build from source.

This often leads to a few issues:

• Features sit in development a lot longer because of the relative high bar for what it means to merge something
• Features that are not quite right need to stay in their unideal state for a long time until we have a major release where we're allowed to break things (which can be years of time)
• Maintenance burden is really high on new features that need to evolve as we search for the backwards compatible way to implement improvements instead of the easier path of breaking things.

A possible solution

It would be nice if we had some mechanism for opting into "unstable" features which were allowed to break at any time.

This could be done through an --unstable-features flag which would allow using these unstable features and which would print out a warning for each feature when it is detected that the feature is being used.

This would give us the ability to more aggressively introduce features and stabilize them when we feel ready (not just when initial development is done).

Where this would help

This would help introducing lots of currently in development features:

• Require more explicit opt-in to unstable wasip3 executor #3315
• Target environments in Spin templates #3294

Open questions

• Should we introduce such a mechanism to spin?
• Should this be an all-or-nothing flag or should we allow opting into specific features?

[fibonacci1729]

This is a great idea! Thanks for writing this up. As a user, I think a feature specific opt in would be generally more useful than an opt into everything unstable.

[itowlson]

I think I'd favour all-or-nothing. I have no great desire to hunt around for the specific incantation that will enable Florp Doubling. (Is it florp-doubling or doubled-florps? Guess I'll try both.) But I'm open to being persuaded otherwise of course!

I like the idea of reporting which unstable features were actually hit. (My Obligatory Bikeshed for this is: I wonder if it would be helpful to accumulate this information and print it out on exit, so it isn't scattered through a pile of logs. But however we do it is fine.)

[itowlson]

A counterpoint to my previous message (wow, that didn't take long): an advantage of choosing individual features is:

• I know that WASI P3 is comfortably within my shipping timeframe, so I want to develop against that.
• However, WASI P3.1 is further out, so riskier and likelier to change, so I don't want to accidentally take a dependency on that.

Hopefully the printout of the used features will mitigate this, but there is always the risk of "oh there's some edge/error case I didn't hit during testing that creates an evil dep." (Although that presumably exists with opt-in as well.)

[lann]

Yeah I'd hope that any "violation" here would result in a big friendly "It looks like you're trying to <double your florps>! That feature is unstable and may go away in a future release, but here's how you enable it: ..."

[fibonacci1729]

Yeah there is definitely an overhead of having opt-in on a feature specific basis. But I guess I'd have a vague worry, as a user, that i would unintentionally opt-in to something i don't want enabled in all-or-nothing situation. And I'd loosely argue that there is, albeit not as heavy an overhead but nonetheless overhead, on having to discover exactly what i'm opting into with an all-or-nothing switch.