thoughts on experimental features

[ctb]

over in #1238 (comment), @luizirber spaketh:

I created a new feature on the Rust side, "experimental". The idea is to allow experimentation without making stability guarantees, including passing all checks required for merging (like wasm support). #1221 is another example of an "experimental" feature.
In order to avoid piling up experimental features, I also propose a requirement that sourmash-Python CAN'T use the "experimental" feature. This keeps us honest, and force stabilization in the Rust side =]
This is sort of equivalent to the nightly features in the Rust compiler.

and I respondedeth:

Hmm. 👎

I instead propose that we add an "experimental" subcommand in sourmash CLI that is explicitly not stable.

Alternatively, as long as it's exposed by the Rust API to Python, I can use it in scripts. So we could keep it away from the CLI, at the cost of not being able to evolve a better CLI as we play with use cases.

Motivation: I do most of my experimentation in Python, as do others, and I think sourmash has benefited substantially from this kind of experimentation. So I want to keep this available!

to which @luizirber volleyed:

Fair point. Note that we can request "experimental" features from the Rust side on any sourmash PRs just fine (add "--features experimental" to the cargo invocation in setup.py), what I'm blocking is merging PRs that use the experimental feature without also "stabilizing" it on the Rust side.

this issue is to continue that conversation, divorced from the specific PR in question!

[ctb]

I have a related question, too. Do we want to do pre-releases? Conda doesn't support them but (as I'm finding out with spacegraphcats) pip/pypi sure does!

It would be somewhat useful for me now that I'm relying on experimental features from sourmash pre-4.0 in genome-grist and spacegraphcats. I could use direct-install-from-github, I suppose, but it's nice to be able to pin versions for benchmarking (as we're seeing in spacegraphcats).