Versioning

What each field means

An Eliya 25.0.4 first GA reports:

The canonical Eliya version is 25.0.4+7-r1. It composes four pieces:

A respin (r2, r3, …) keeps the upstream +7 and advances the r counter:

The dedicated brand-identity system properties (java.vendor = Asymm Systems; java.vendor.version = Eliya-25.0.4) and the release file ($JAVA_HOME/release) carry the same information in structured fields for machines that parse it; the version string is for humans.

Four pin patterns

Pins divide into two layers. Machine-grade pins are cryptographic and byte-exact, and build tools, signature verifiers, and container runtimes consume them. Human-grade pins are the ones a person can read off a banner and type into a Dockerfile or a support ticket. The two are not interchangeable, and each audience reaches for the one it can actually use.

Four patterns cover how operators pin Eliya, two mutable (the tag moves under you) and two immutable (the bits never change once pinned). Pick by how much you want the deployment to follow the published cadence versus stay byte-frozen until you advance it yourself.

Pattern 1: LTS-track moving tag (mutable)

:25-lts advances on every quarterly CPU and every out-of-cycle CVE respin. With imagePullPolicy: Always in Kubernetes (or equivalent), each pod restart picks up the latest published build. Best for teams that trust the published cadence and want automatic uptake of every build without operator action.

Pattern 2: CPU-track moving tag (mutable within a CPU window)

:25.0.4 stays on the 25.0.4 quarterly window; it advances only when a respin (out-of-cycle CVE rebuild) lands within that window, never to the next CPU. You explicitly bump the tag string at each quarterly CPU (:25.0.4 → :25.0.5). Best for environments that require change-management sign-off per quarter but want respins inside the quarter picked up automatically.

Pattern 3: Per-build immutable handle (immutable, 25.0.4 onwards)

From 25.0.4, every Eliya build carries a revision ordinal r<N>: the first build of 25.0.4 is r1, the first respin is r2, and so on. The Docker tag :25.0.4-r1 and the archive filename eliya-jdk-25.0.4+7-r1-linux-x64.tar.gz (where +7 is upstream OpenJDK's GA promoted-build coordinate) point at one specific build and never advance. Best for change-management sign-off per build, reproducible CI pipelines, and any environment where "the exact same build" matters but a SHA digest is too unwieldy to type or remember.

Pattern 4: Cryptographic content pin (immutable, byte-exact)

The only pin that cryptographically guarantees byte-identical bits. For containers, the OCI image digest @sha256:<digest>; for archives, the SHA-256 from the signed SHA256SUMS.txt.asc on each GitHub Release. Required by compliance buyers and supply-chain auditors; recommended for any regulated environment. See verify your download for the SHA-256 + GPG ceremony.

Summary table

The four patterns at a glance, with the operational scenario each fits:

A common operational practice layered on top: stay on a specific version indefinitely (e.g., remain on :25.0.4-r1 beyond the next quarterly CPU), applying only respins for actively-exploited CVEs. That's Pattern 3 or Pattern 4 with deferred quarterly bumps, not a separate pin mechanism.

Which pin matches which audit framework?

Most compliance frameworks (PCI DSS, HIPAA, SOX, FedRAMP, EU CRA) call for signed artefacts plus SBOMs plus vendor attestation. The SHA-256 + GPG chain is what they ask for; the human-readable handles are operational ergonomics on top of that. If you only record one identifier in your audit trail, record the SHA-256 of the bytes you installed. Everything else is supporting context.

Where each piece of identity lives

The version string carries per-build technical identity. Brand identity lives in dedicated OpenJDK fields. Cryptographic identity lives in the signed checksums file and the OCI manifest. Each surface has the field it actually uses.

In the version string (banner / JAVA_RUNTIME_VERSION)

• $VNUM (25.0.4): JDK version
• Upstream $BUILD (+7): source-base coordinate
• Eliya revision (r1): per-build identity in $OPT

In dedicated brand-identity fields

• java.vendor = Asymm Systems
• java.vendor.version = Eliya-25.0.4
• release file IMPLEMENTOR = Asymm Systems
• release file IMPLEMENTOR_VERSION = r1

In machine-grade pin channels (not in the version string)

• Artefact SHA-256: signed SHA256SUMS.txt.asc on each GitHub Release
• Docker image digest: OCI manifest, addressable via @sha256:
• Mirror commit SHA, upstream tag, upstream promoted-build number: release file (SOURCE, ELIYA_MIRROR_COMMIT, ELIYA_UPSTREAM_TAG, ELIYA_UPSTREAM_BUILD)

Four exceptions to the canonical form

The canonical Eliya version 25.0.4+7-r1 renders verbatim in most surfaces. Four exceptions exist, each forced by an external standard. Listed for completeness; you do not need to memorise them unless you write tooling that parses Eliya identifiers across package formats.

The 25.0.3 historical note

Eliya 25.0.3 (published 2026-06-10) shipped with java.runtime.version = 25.0.3+24-Eliya. The +24 is the count of commits on the Eliya source mirror since the upstream jdk-25.0.3-ga tag, a per-commit quantity, not a per-promoted-build counter. This is a JEP 322 grammar-valid string but a non-canonical derivation: a reader of the spec would expect +24 to indicate 24 promoted builds, when it actually indicates 24 commits past upstream GA.

The 25.0.3 release stays frozen as published. The scheme described on this page is effective from 25.0.4 onward. The SECURITY.md documents both schemes; the SHA-256 + GPG verification chain is unchanged across the transition.