Operator procedure OP–01 Translation layers
Server-side compatibility, honestly
A stock Java server accepts exactly one protocol: its own. Every “this server supports 1.8–1.21” banner you have seen is a server-side translation stack at work. That has two consequences worth stating plainly: the client cannot force a bridge into existence, and a version banner is a claim, not a measurement.
Direction plate Server-side only
The direction semantics people mix up
| Layer | Runs on | Lets in |
|---|---|---|
| ViaVersion | the server / proxy | newer clients than the server version |
| ViaBackwards | the server, on top of ViaVersion | older clients, within documented limits |
| ViaRewind | the server, on top of ViaBackwards | the 1.8.x / 1.7.x generation of old clients |
Translation is lossy at the edges: blocks, combat timing, and items that do not exist in one version get approximated in the other. “Connects” and “plays well” are different bars, and only the first one is a protocol fact.
Attestation / required
What an operator can honestly publish
- The server’s native version and the exact translation layers installed, with their versions.
- The client range actually tested by a person, dated — not the theoretical range of the plugin stack.
- Known rough edges per client era, so old-client players know what they are choosing.
Native version, bridge inventory, tested range, and date form the minimum useful operator attestation. The current record contains no server-specific attestations, so the workbench reports only published protocol facts and leaves bridge behavior Unknown.
Migration order Rehearse on a copy
Migrating a server across eras
- 01Snapshot the world directory (one-way rule applies server-side too).
- 02Rehearse the upgrade on the copy; world conversion time and plugin breakage show up there, not in production.
- 03