Builds, versions and what changed
Every build has an identity, and what changed between two of them is generated rather than written.
For whoever owns compliance, or has to answer a test house.
A build is identified, not described
Every release is published by one signed pipeline into one registry. Nothing else may write a release, and a demo is a mode of a release rather than a separate thing that happens to look like it.
That is what lets us answer, for any build you have ever been served, exactly which version of the game it was.
What identifies a build
- release_id
- The build itself. Carries the version and the source commit it was made from.
- math_version
- The version of the mathematics a game uses. Any change to how a game resolves is a new one of these, never an edit to an old one.
- rules_version
- The published player rules the build obeys.
- client_version and server_version
- The two halves of the game, versioned separately.
- bundle_hash
- The built client as one number, over every file the build produced. A bundle you were served can be checked against the release it claims to be, and the pipeline refuses to publish a release whose demo host is serving anything else.
- core_hash
- The hash of exactly the files that decide an outcome. A build whose core hash moved while its maths version stood still is reported as a fault rather than as a note.
- core_files_hash
- Which files that covered, rather than what was in them. It is what separates a change to the game from a change to what we consider part of the game, and both of those move the core hash.
Release notes you did not have to write
What changed between one release and the one before it is generated from the registry, and it answers the only question a partner and a test house both ask: did the game change, or did the picture of it change.
A release is classified by what moved. Mathematics, rules, or presentation. A presentation release is one you can take without re-reading anything.
The metadata feed
Identifiers, versions, hashes, demo links and the approved facts for every released title, generated from the registry rather than typed into a spreadsheet per partner. It is a single request, it is never cached between us and you, and it cannot describe a build that was never released.
It is issued against a partner session rather than published openly, because it carries the lifecycle of titles that are not announced. Ask us and we will set yours up during the sandbox step.