Identifier Version Resolution Rule¶
Resolution rule — instantiates Persistent Identifier Stewardship
The policy that decides which version a bare token resolves to — latest, pinned, or as-of a date — when one persistent identifier stands over many versions.
Identifier Version Resolution Rule answers a single, sharp question: when one durable token stands over an entity that has many versions, which version should a request without further qualification get? Its defining move is to make the version dimension of resolution an explicit, stated policy rather than an accident of storage — a bare token resolves to the latest, an exactly-qualified token pins a specific version, and a date- or channel-qualified token resolves as-of some point. It governs the choice among currently valid versions only; it says nothing about what happens when there is no valid target at all — a moved, merged, or withdrawn entity is another mechanism's concern. This rule's whole scope is disambiguating "which of the versions that legitimately exist right now?"
Example¶
In the npm package registry, a project that depends on lodash can ask for it three ways, and a version resolution rule decides each. A bare lodash resolves through the latest dist-tag to whatever the maintainers currently designate current. A pinned lodash@4.17.21 resolves to exactly that immutable release. A range like ^4.17.0 resolves to the newest release compatible under Semantic Versioning,[n1] and a lockfile freezes that choice as-of the moment it was written.
When the maintainers publish 4.17.22, the rule's effect is surgical: the bare latest request now points at the new release, while every pinned reference and every lockfile entry is untouched — they still resolve to the exact versions they named. One stable package identifier thus serves two opposite needs at once: "give me the current one" and "give me precisely this one," with the resolution rule deciding which reading applies to each request.
How it works¶
The rule is a small grammar plus a default:
- Set the default. Decide what a bare, unqualified token resolves to — latest, latest-stable, or a required explicit pin.
- Define the qualifier grammar. Specify how requests may narrow the choice: exact version, compatibility range, as-of date, or release channel.
- Read version state. Consult each version's metadata — its identifier, release date, and standing (stable, prerelease, deprecated) — to evaluate the request.
- Bind the mapping's version dimension. Set which concrete version the token's current mapping resolves to, so the resolver can execute it.
The rule decides; the Persistent Identifier Resolver Service executes the decision at request time.
Tuning parameters¶
- Default target — bare token means latest, latest-stable, or "must pin." Convenient defaults ease casual use; strict pinning forces reproducibility.
- Qualifier expressiveness — exact pins only, versus ranges, dates, and channels. Richer grammar serves more needs but multiplies edge cases.
- Mutability of "latest" — a floating pointer that moves on each release, or immutable snapshots plus an alias. Floating is convenient; immutable is reproducible.
- Prerelease visibility — whether prereleases are eligible for default resolution or hidden behind an opt-in channel.
- Deprecated-version handling — a still-published but deprecated version resolves with a warning, is skipped, or is refused — while remaining distinct from a withdrawn entity, which is the tombstone policy's domain.
When it helps, and when it misleads¶
Its strength is that one persistent identifier can honor both continuity and precision: a citation can name the current version and a reproduction can pin an exact one, without minting a separate token for every release. It makes the version question a governed policy instead of leaving each caller to guess.
Its failure mode is the treachery of a floating "latest": a bare token that silently upgrades under its users breaks reproducibility, and a surprise major-version jump can shatter downstream work that assumed stability. The subtler failure is an ambiguous default nobody wrote down, so two callers resolve the same token to different versions. The classic misuse is mutating a published version in place — editing the bytes behind 4.17.21 — which quietly falsifies every pin that trusted it. The discipline that keeps it honest is immutable versions plus explicit pinning: let "latest" float for convenience, but make each concrete version permanent so a pin is a promise.
How it implements the components¶
Identifier Version Resolution Rule realizes the version-selection slice of the archetype — the parts that resolve one token across many states:
version_selection_policy— it is this policy: the stated rule mapping a bare, pinned, or qualified request to a concrete version.resolver_mapping_record— it binds the version dimension of the mapping, setting which concrete version the token currently resolves to for the resolver to serve.
It does NOT decide what happens to a moved, merged, or withdrawn entity (alias_redirect_and_tombstone_map, lifecycle_event_update_rule) — that's Redirect and Tombstone Policy; this rule chooses only among versions that are currently valid. Where that policy handles the absence of a valid target, this rule handles the abundance of them.
Related¶
- Instantiates: Persistent Identifier Stewardship — the rule governs the version dimension of resolution.
- Sibling mechanisms: Persistent Identifier Resolver Service · Resolver Landing Page · Redirect and Tombstone Policy · Custodial Transfer Protocol · Resolution Link Checker · Identifier Registry · Identifier Minting Workflow
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Identifier Version Resolution Rule operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it the policy that decides which version a bare token resolves to — latest, pinned, or as-of a date — when one persistent identifier stands over many versions
Independent corroboration: The frozen evidence defines Identifier Version Resolution Rule as 'The policy that decides which version a bare token resolves to — latest, pinned, or as-of a date — when one persistent identifier stands over many versions', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Pinning, compatible ranges, precedence, and immutable releases arise from software package and semantic-versioning practice.
Related originating lineages:
- Library & Information Science — Edition control and persistent work-versus-version identity provide an older record-management parallel.
Review resolution: Both reviewers independently assign computer_science as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The evidence describes one principal historical lineage. Its defining controls and vocabulary remain bounded to a particular professional or technical practice. The encyclopedia entry generalizes the established mechanism without creating a new composite lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Semantic Versioning (SemVer 2.0.0) — the convention that a MAJOR.MINOR.PATCH version communicates the nature of a change, and that a published version, once released, is immutable. Version resolution rules lean on exactly this contract: ranges are safe only because a patch release promises not to break compatibility, and pins are meaningful only because the bytes behind a version never change. ↩