barrel_mcp_version (barrel_mcp v3.0.1)

Protocol revision comparison.

Revisions are an enumerated set, not an ordered scalar. Today's identifiers are date-shaped and so happen to sort lexicographically, but a future one need not be, and a string from a peer we do not recognise must not accidentally compare as newer than everything we know. <<"zzz">> > <<"2025-11-25">> is true and meaningless.

Every ordering question therefore goes through the registry in barrel_mcp.hrl rather than through term comparison. An unknown revision is treated conservatively: it satisfies no minimum.

This mirrors the reference Python SDK's version module, which reaches the same conclusion for the same reason.

Summary

Types

feature/0

Functions

all()

Every revision this library speaks, newest first.

era(Version)

Which era a revision belongs to, or unknown.

feature(Feature, Revision)

Whether a revision has a feature.

has(Feature, Revision)

feature/2 as a boolean, for the callers that treat compatibility as yes.

is_at_least(Version, Minimum)

Whether Version is a known revision at least as new as Minimum. Use this to gate anything on a revision rather than comparing the binaries.

is_known(Version)

Whether this is a revision the library knows about at all.

Types

feature/0

-type feature() ::
          batch_receive | roots_list_changed | tasks | tasks_extension | output_schema |
          output_schema_any_root | elicitation | elicitation_url | title | icons.

Functions

all()

-spec all() -> [binary()].

Every revision this library speaks, newest first.

era(Version)

-spec era(binary()) -> legacy | modern | unknown.

Which era a revision belongs to, or unknown.

feature(Feature, Revision)

-spec feature(feature(), binary() | undefined) -> enabled | compatibility | disabled.

Whether a revision has a feature.

Not every feature is monotonic, so this cannot be a threshold on is_at_least/2. Batching is required at 2025-03-26 and removed at 2025-06-18; tasks move from the core protocol into an extension. A table states each one exactly.

compatibility means the revision does not require the feature and does not forbid it either, and we choose to accept it. undefined for a revision that has not been negotiated yet answers disabled: we cannot know what the peer speaks, and guessing wrong on the permissive side is what a limit exists to prevent.

has(Feature, Revision)

-spec has(feature(), binary() | undefined) -> boolean().

feature/2 as a boolean, for the callers that treat compatibility as yes.

is_at_least(Version, Minimum)

-spec is_at_least(binary(), binary()) -> boolean().

Whether Version is a known revision at least as new as Minimum. Use this to gate anything on a revision rather than comparing the binaries.

An unknown Version returns false: we cannot place it, so we do not assume it is new enough. An unknown Minimum is a bug in the caller, not a runtime condition, so it raises.

is_known(Version)

-spec is_known(binary()) -> boolean().

Whether this is a revision the library knows about at all.