Rust API

version.TmuxVersion.meets

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

meets ( self , required : &ReleaseVersion ) → bool method [source] ¶ method [source] ¶ meets

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.

Examples

use libtmux::TmuxVersion;

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

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

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

0 declared, 0 inherited