mise up reports "All tools are up to date" for letter-suffixed versions (tmux 3.7b -> 3.7c)

[Susensio]

Describe the bug

Tools whose versions use a trailing-letter suffix — tmux 3.7a/3.7b/3.7c — are never detected as outdated by mise upgrade (alias mise up), so -b/--bump never fires either.

With tmux = { version = "latest" } in the config, 3.7b installed, and 3.7c available, both mise up tmux and mise up --bump tmux print "All tools are up to date".

Steps to reproduce

mise: 2026.8.10, tmux backend: aqua:tmux/tmux-builds

1. Install tmux at 3.7b with tmux = "latest" in ~/.config/mise/config.toml
2. mise ls-remote tmux → latest line is 3.7c
3. mise latest tmux → 3.7c
4. mise up --bump --dry-run tmux → mise All tools are up to date

Meanwhile mise install tmux correctly upgrades to 3.7c, and mise ls tmux shows the latest request bound to 3.7b.

Expected behavior

mise up/mise up --bump should flag 3.7b as outdated and upgrade to 3.7c (leaving latest as the request).

Root cause

is_outdated_version in src/toolset/outdated_info.rs (v2026.8.10, line ~420):

pub fn is_outdated_version(current: &str, latest: &str) -> bool {
    if let (Some(c), Some(l)) = (Version::new(current), Version::new(latest)) {
        c.lt(&l)
    } else {
        current != latest
    }
}

crate::Version is versions::Version from fosskers/versions v7 (see Cargo.toml). That crate does parse these strings (its Last chunk handles patterns like 3.7b), but its Ord implementation is broken for them: cmp returns Equal while PartialEq says the values are unequal. So c.lt(&l) is false, the else fallback is never reached (both parse as Some), and the installed version is treated as current.

Minimal repro (the same crate mise uses):

use versions::Version;
fn main() {
    println!("{:?}", Version::new("3.7b").cmp(&Version::new("3.7c"))); // Equal
    println!("{}", Version::new("3.7b") == Version::new("3.7c"));      // false
}

PartialEq disagrees with Ord here, which violates Ord's contract — likely a bug in fosskers/versions, but mise should also be robust to it (e.g. fall back to a string comparison when suffix ordering is ambiguous, or check !c.eq(&l) before trusting lt).

Workaround

mise install tmux re-resolves latest against the full remote list and upgrades correctly.

Update

Verified with the actual crate versions (Rust repro using versions crate):

• versions v7 (what mise pins in Cargo.toml): broken — cmp("3.7b","3.7c") == Equal while PartialEq says false.
• versions v8 (released 2026-09-05): fixed — cmp == Less, lt == true.

So the upstream fix already landed in v8; mise likely only needs to bump the dependency. Filed upstream as fosskers/versions#87.

Update 2

This is already a known, fixed crate bug. src/lockfile.rs on main documents it and cites fosskers/rs-versions#39 (closed after the v8 fix; my duplicate report fosskers/versions#87 is flagged as such). Verified on the crate directly:

• versions v7 (current dep in Cargo.toml): cmp("3.7b","3.7c") == Equal, lt == false → mise up treats tmux as up to date.
• versions v8 (released 2026-09-05): cmp == Less → correct.

is_outdated_version (outdated_info.rs:468) is still the raw c.lt(&l) on main. The lockfile workaround in lockfile.rs only covers the lockfile's newest-first ordering, not mise up. So the fix here is a bump: versions = "8". If a bump is undesirable, a guard like !c.eq(&l) && c.le(&l) (fall back to string compare) would also harden is_outdated_version.

[jdx]

Thanks for the detailed report and upstream research. I confirmed the v7 comparison bug and opened #13119 to update versions to v8.

The PR includes regression coverage for both directions: 3.7b → 3.7c is outdated, while 3.7c → 3.7b is not. I used the dependency fix rather than the proposed !c.eq(&l) && c.le(&l) guard because v7 can report the parsed values as order-equal in both directions, which would risk treating a downgrade as an upgrade.

AI-assisted — Tool: Codex; model: openai/gpt-5; version: unavailable.