Rust API

version.TmuxVersion.has_behavior

Rust

Python Unavailable
Ruby Unavailable
Lua Unavailable
TypeScript Unavailable
Rust
Go Unavailable
Java Unavailable
.NET Unavailable
C++ Unavailable
Swift Unavailable

Module: version
Declared in: TmuxVersion
Package: libtmux
Source: crates/libtmux/src/version.rs

has_behavior ( self , needs : &ReleaseVersion ) → bool method [source] ¶ method [source] ¶ has_behavior

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.

Examples

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));

0 declared, 0 inherited