jdx/mise · error

{} backend does not support version_order

Error message

{} backend does not support version_order

What it means

The default `Backend::version_order` implementation returns source ordering and only permits that; any backend that has not opted in to custom ordering rejects a user-supplied `version_order` option outright. This protects tools with opaque, non-semver version schemes from being reordered incorrectly.

Source

Thrown at src/backend/mod.rs:4099

    /// (`1.0.0-rc1`, `1.0.0-dev.5`, ...). Callers that have opted into
    /// pre-releases pass `false` to keep those tags in the match set.
    fn fuzzy_match_filter(
        &self,
        versions: Vec<String>,
        query: &str,
        filter_prereleases: bool,
    ) -> Vec<String> {
        fuzzy_match_versions(versions, query, filter_prereleases)
    }

    /// Select the ordering policy supported by this backend.
    ///
    /// Backends must opt in explicitly before `version_order` can affect remote
    /// version listing or resolution. This keeps opaque version schemes
    /// source-ordered by default.
    fn version_order(&self, opts: &ToolVersionOptions) -> eyre::Result<VersionOrder> {
        if opts.opts.contains_key("version_order") {
            bail!("{} backend does not support version_order", self.get_type())
        }
        Ok(VersionOrder::Source)
    }

    /// The key of the remote-version cache entry these listing options select.
    async fn remote_version_cache_context_for(
        &self,
        config: &Arc<Config>,
        listing_opts: &ToolVersionOptions,
        has_local_version_listing_override: bool,
    ) -> eyre::Result<Option<String>> {
        // The listing-relevant options shape the cached list, so they belong in its key.
        // Only local overrides count: a registry-supplied value is identical for everyone, so
        // one entry is correct for it, and leaving it out keeps the shared versions host
        // available for the default case.
        let opt_context = has_local_version_listing_override.then(|| {
            listing_option_digest(listing_opts, self.remote_version_listing_tool_option_keys())
        });

View on GitHub (pinned to afd2eddd3a)

Solutions

1. Remove the `version_order` option from that tool's configuration.
2. Use a backend that explicitly supports version_order if semver sorting is required.
3. Request upstream support by implementing `version_order` in the backend if it is your own plugin/backend.

Example fix

// before (mise.toml)
[tools]
"github:owner/repo" = { version = "latest", version_order = "semver" }
// after
[tools]
"github:owner/repo" = "latest"

// before setting the option, check backend support in mise docs
// or defensively strip the option per backend:
const SUPPORTS_VERSION_ORDER = new Set(["node", "python"]); // example
if (!SUPPORTS_VERSION_ORDER.has(backend)) delete toolOpts.version_order;

When it happens

Trigger: Setting `version_order = "semver"` (or "source") in a tool's options for a backend that does not override `version_order`, e.g. in mise.toml tool settings or `mise ls-remote --version-order` style usage against an unsupported backend.

Common situations: Copy-pasting a version_order option that works for one backend (like a core plugin) to another backend (asdf/vfox/github backend); assuming all backends support semver sorting of versions like `latest`, `lts/*`.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• unsupported aqua package type: {t}
• package type `cargo` is not supported in the aqua backend. U
• package type `go_install` is not supported in the aqua backe
• package type `{}` is not supported in the aqua backend. Use
• cargo-binstall cannot honor cargo install-only tool option(s

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/f5d9d00384dd7a51. Report an issue: GitHub.