# version.TmuxVersion.has_behavior

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

```
version.TmuxVersion.has_behavior(self, needs: &ReleaseVersion) -> bool
```

Report whether this version's tree carries a capability's behavior.

This is `Self::require`'s refusal rule in boolean form, so a caller
gating a specific capability -- or a test predicting which branch
`require` takes -- uses the same rule `require` does, rather than an
independently derived one that can drift from it. [`Self::meets`] is
a different, deliberately non-identical rule: it clamps *every*
development identifier -- `next-X.Y` included, not only a bare
`master` -- to "no more than the crate's minimum supported release",
so it refuses any requirement above that floor regardless of what the
build's own next-release number is. This reads `next-X.Y` as the real
release `X.Y` instead, so the two disagree for any development build
checked against a requirement above the floor: [`crate::since`] holds
several, and this crate's own tmux-matrix probe self-reports
`next-3.9`. Checking a capability with `meets` instead of this
refuses that capability on a development build that already has it.

## Example

```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` already contains 3.7's behavior, so this reports it --
// unlike `meets`, which clamps every development identifier to the
// floor and would refuse it.
assert!(next.has_behavior(&capture_line_flags));
assert!(!next.meets(&capture_line_flags));
```