# io.github.libtmux.TmuxVersion.TmuxVersion

- **Module:** io.github.libtmux.TmuxVersion
- **Package:** io.github.libtmux:libtmux
- **Language:** Java
- **Kind:** struct
- **Source:** https://github.com/libtmux/libtmux-java/blob/842228310449e879ebcaa3f910597757c9dbffd6/libtmux/src/main/java/io/github/libtmux/TmuxVersion.java#L35
- **Page:** https://libtmux.org/en/java/latest/reference/io-github-libtmux-tmuxversion-tmuxversion/

A released tmux version, ordered the way tmux releases are.

tmux numbers a patch release with a letter rather than a third number: 3.7a follows 3.7, and
3.2a follows 3.2. Comparing the text alone gets that wrong in both directions, and a feature gate
that gets it wrong reads a format the running tmux does not have.

Between releases, tmux reports itself as {@code next-M.m}: a development build tracking toward
the release named, not that release itself. It has everything the previous release shipped and
nothing later's patches guarantee, so it sorts strictly between the two — above every patch of the
release before it, below the release it names and every patch of that.

A release candidate, {@code 3.8-rc}, compares equal to the release it names. tmux freezes
features at the candidate, so it has everything the release will and differs only in fixes —
measured, not assumed: a 3.8 candidate writes JSON layouts and empties a dead pane's pid exactly
as 3.8 does, and a feature gated on 3.8 works on it. It is not {@code equals} to the release, and
it is written back exactly as tmux wrote it, which matters beyond display: every capture is
fenced on the version tmux reports, and a candidate printed as {@code 3.8} failed that fence on
every read.

## Members

- `TmuxVersion` (method): A release or a development build, without a release candidate.
- `parse` (method): Reads what tmux reports for {@code #{version}}.
- `atLeast` (method): Whether this version has everything the given one has.
- `compareTo` (method)
- `toString` (method)