# version.TmuxVersion.meets

- **Module:** version.TmuxVersion
- **Package:** libtmux
- **Language:** Rust
- **Kind:** method
- **Source:** https://github.com/libtmux/libtmux-rs/blob/f0e37052c232636b61d095817046e6bfc8f2ca40/crates/libtmux/src/version.rs#L469
- **Page:** https://libtmux.org/en/rs/latest/reference/version-tmuxversion-meets/

```
version.TmuxVersion.meets(self, required: &ReleaseVersion) -> bool
```

Return whether this version supports a required numbered release.

Development identifiers meet only requirements at or below the crate's
minimum supported release; they are not promoted to an invented release.
A `next-X.Y` identifier's own release number is not read here even
when `required` is that same `X.Y` or earlier -- this is a floor
check, not a capability check. Asking "does this tree already contain
a capability that shipped at version V" is [`Self::has_behavior`]'s
question, not this one; a call site gating a specific capability
behind a release above [`Self::MIN_SUPPORTED`] almost always wants
that instead, or it refuses a development build that already has the
capability it is checking for.

## Example

```rust
use libtmux::TmuxVersion;

let version = TmuxVersion::parse_output(b"tmux 3.2a\n")?;
assert!(version.meets(&TmuxVersion::MIN_SUPPORTED));
```

## Example

The English verb suggests this answers "is a capability available", but on a development build it can refuse one that is already there:

```rust
use libtmux::{ReleaseSuffix, ReleaseVersion, TmuxVersion};

let next = TmuxVersion::parse_output(b"tmux next-3.9\n")?;
let capture_line_flags = ReleaseVersion::new(3, 7, ReleaseSuffix::FINAL);

// `next-3.9`'s tree already has 3.7's behavior, but this clamps every
// development identifier to the crate's floor, so it says no anyway.
// `TmuxVersion::has_behavior` is the question that says yes.
assert!(!next.meets(&capture_line_flags));
assert!(next.has_behavior(&capture_line_flags));
```