| Age | Commit message (Collapse) | Author |
|---|
|
The matrix marked every accepted pair with a plain tick, which reads as
"everything works". It does not. ProtocolVersion bumps PATCH for sub-channels a
peer can safely ignore, so Paper 1.3.0 (protocol 1.0.1) against Velocity 1.1.0
(1.0.0) completes the handshake and then silently drops cross-server direct
messages — the very feature that PATCH was bumped for. An operator reading the
tick had no way to learn that, and the pages around it repeated the claim.
The handshake is settled by MAJOR and MINOR alone, so any difference left once a
pair is accepted is a feature the newer end offers and the older will never
answer. Those pairs now carry a warning that says which end lags. Naming the
feature would take a protocol-version-to-feature table on the website, which
would drift from the protocol it describes, so the warning stays general and
leaves the reader one hop from the compatibility page.
The handshake verdict keeps the three checks that mirror Velocity's gate, with
the new one layered after them, so the mirror stays honest. isCompatible now
holds for a degraded pair, which does connect.
Cells are built once per pair in a computed instead of recomputing on each of the
template's reads, which a third state would otherwise have multiplied.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
The download cards and the compatibility matrix derived each plugin's version
from the release tag, which cannot hold for a unified `vX.Y.Z` release: it
carries both JARs and their versions need not agree. v1.3.0 shipped Paper 1.3.0
alongside Velocity 1.2.0.
So the download page advertised Paper v1.2.2 and Velocity v1.1.0, two
generations stale, because it searched `paper/v` and `velocity/v` tags first and
fell back to a unified tag only when none existed. The matrix meanwhile put a
Velocity v1.3.0 on its axis that was never released, leaving no row for the
proxy build operators actually run.
Both now pick releases by the JARs attached to them and take the version from
the file name, the only place it is stated. Tag shape stops mattering: a
platform-specific tag and a unified one are alike just releases that happen to
carry a given JAR.
Releases rank by publication time rather than by API response order, which
follows tag creation instead: velocity/v1.1.0 precedes the later-published
paper/v1.2.2.
A version is listed once even when a later unified release re-attaches an
unchanged JAR, which release.yaml does whenever only the other platform was
bumped. Otherwise the matrix would carry one version twice, under two protocol
versions if the protocol had moved in between.
Tests run in CI from here on. They need an explicit path because Bun does not
discover tests inside dot-directories.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
Update the compatibility matrix logic and documentation to reflect the actual
implementation: only Velocity performs the handshake validation, not Paper.
- Remove velocity-too-new and velocity-too-old from CompatibilityResult
- Simplify checkCompatibility() to check only if Velocity accepts Paper
- Update reason labels to clarify direction (Paper vs Velocity perspective)
- Add note distinguishing plugin version from protocol version
- Clarify Velocity-only validation in the protocol section
- Rewrite compatibility rules from Velocity's perspective
Paper only sends the handshake; it does not validate Velocity's version.
This aligns documentation with the actual behavior in
platform-velocity/.../PluginMessageHandler.kt.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
Add a dynamic compatibility matrix (GitHub Releases + ProtocolVersion.kt at
each tag) shown on the home page, download page, and a new reference doc.
Split protocol theory and rolling-update rules out of the Velocity feature
guide into the new compatibility reference, and simplify the download notice.
Also set explicit GitHub release titles in the Paper / Velocity workflows so
the awkward paper/v* tag prefix is not the user-facing label.
Co-Authored-By: Claude <noreply@anthropic.com>
|
