Releases
At launchA release is a set of artefacts cut together and versioned together: the server and the CLI as container images, the authenticator app on the two app stores, and the SDKs on their language registries. Versions are semantic, and the number is a promise about the gRPC surface — a minor release only adds to it. Every artefact is published with a digest you can pin and a signature you can check, because software you host yourself is software you should be able to verify yourself.
Who this is for: whoever decides what version runs in production, and has to answer what changed and how they know the bytes are the ones Ydentifi published. If you are installing for the first time, start at Quickstart instead.
Ydentifi is pre-launch. This page describes the shape a release takes — the artefacts, the version contract, and the verification steps — so that integrators can plan against it. There is nothing to download from it today, and the registry paths below are the planned ones, fixed when the first release is published.
What a release contains#
| Artefact | Comes from | Versioned as | License |
|---|---|---|---|
| Server | ghcr.io/ydentifi/ydentifi-server | semantic | commercial |
CLI (ydfi) | ghcr.io/ydentifi/ydfi | tracks the server | commercial |
| Authenticator app — iOS | App Store | store build number | free |
| Authenticator app — Android | Google Play | store build number | free |
| Backend SDKs (8 languages) | each language’s own registry — module proxy, PyPI, npm, Maven Central, NuGet, crates.io, RubyGems, Packagist | semantic, independent | Apache 2.0 |
| Device SDKs (Swift, Kotlin) | Swift Package Manager, Maven Central | semantic, independent | Apache 2.0 |
The two halves are deliberately different. The server and CLI move together — they are one deployment and a mismatched pair is a support problem nobody needs. The SDKs move independently, because a Python fix should not oblige a Java bump, and because they are on registries whose conventions are not Ydentifi’s to override.
What the version number promises#
An RPC, a field, or a behavior integrators could reasonably depend on is gone or changed meaning. Never silent; always in the release note, with the migration.
New RPCs, new optional fields, new factor capabilities. Existing calls keep working unchanged. This is where nearly everything lands.
Behavior that did not match the documentation now does. No surface change at all — if a fix needs one, it is a minor.
The number is a statement about the gRPC surface, not about how much code moved. That is the surface integrators build against, so it is the only one a version can promise anything about. Internals are free to change in any release; the wire contract is not.
A server runs the current major and the one before it. An SDK a major version behind keeps working while you migrate, rather than failing the moment the server is upgraded. Two majors behind is not supported — calls are rejected with a typed error naming the version, not a generic failure. See Errors.
Verifying what you downloaded#
Two independent things are worth checking, and they answer different questions.
Pin the digest
A tag is a label and labels can be moved; a digest is the content itself. Deploy by digest and you get the same bytes on every node, on every restart, forever — regardless of what the tag points at later.
Check the signature
The digest proves every node ran the same thing. The signature proves that thing came from Ydentifi. You want both: a pinned digest of an artefact nobody signed only guarantees you are consistently running something unknown.
Read what changed
Release notes always call out, in this order: breaking surface changes, database migrations, certificate and PKI changes, then everything else. The first three are the ones that can interrupt a deployment, so they never sit below the fold.
The signing scheme, the public keys, and the ydfi command that checks them are not published
yet — and until they are, this page will not pretend otherwise. Signatures will be hybrid, matching every other
signature Ydentifi produces: a classical algorithm and a post-quantum one together, so a break in either alone does not
forge a release. See Security model.
Release notes#
Every release gets a note, and the note is written for the person doing the upgrade rather than the person who wrote the code. That means it leads with consequences, not commits.
| Always stated | Because |
|---|---|
| Breaking surface changes | Integration code has to change before the upgrade, not after. |
| Database migrations | They are applied when the stack starts, before the server, with every server of the previous release stopped (see Upgrading), and take time proportional to your data. |
| Certificate & PKI changes | Anything touching trust can lock a fleet out of its own server. |
| Default limit changes | A tightened default is indistinguishable from a bug at three in the morning. |
| Minimum supported SDK | So you learn it here rather than from a rejected call. |
Security fixes are described plainly once a fixed version exists, including what an unpatched deployment is exposed to. Withholding that detail protects nobody who has already upgraded and leaves everyone who has not in the dark.
Readiness#
What is decided, and what is still open. This ledger is the actual state of release engineering, not a roadmap.
Semantic versioning against the gRPC surface, with the current major and the one before it supported.
Container-first distribution for server and CLI; SDKs on each language’s native registry.
Hybrid signatures — classical plus post-quantum — consistent with every other signing layer.
Signing transport — whether signatures travel as container-registry attestations or as detached files alongside each artefact. This decides what an air-gapped operator has to copy across.
Support window length — how long a major keeps receiving security fixes after its successor ships.
Registry paths — planned above, fixed when the first release is published.