Release management
Controlling exactly what goes out in each release, which code, settings and version number, with checks that prove the build is the one you meant to ship.
Updated October 2026 · with examples from our own builds
What does release management mean in practice?
Release management ties each build to a version, a commit and the settings it was built with, and runs checks before anything is shared: is this the right backend address, the right signing certificate, is any placeholder content left in?
It prevents a particular kind of embarrassment: two different builds with the same version number, a release that points at a developer's laptop, or test content reaching a live page. All of these pass every functional test.
Support depends on it as well. When a user reports a bug, you need to know exactly which build they have.
Release management at a glance
- Records per build
- Version, commit, checksum and settings
- Checks before sharing
- Target backend, signing and placeholders
- Makes possible
- Knowing exactly what each user is running
Where has release management come up in our builds?
Every APK is recorded with its git tag, commit, sha256, signing certificate and the backend commit it expects. Two builds had already shipped under one version number with different contents, and one that said BUILD SUCCESSFUL still pointed at the build laptop because Metro had cached the bundle, so a verifier now reads the API address out of the built APK before anything is shared.
Each release is tagged in git, native libraries are limited to arm64-v8a and armeabi-v7a and checked on the built bundle, 540 console calls are stripped from release builds, and Sentry source maps upload during the release build.
Every made-up value from the design hand-off lives in one file behind a HAS_PLACEHOLDER_CONTENT flag; while it is true, check:placeholders fails and npm run verify:prod stops.
Common questions about release management
How do I know which version of my app a user has?
Every build should carry a unique version and be recorded against its commit. A version number in a bug report then points to the exact code.
Can a release pass all its tests and still be wrong?
Yes: it can be built against the wrong server, signed with the wrong key or carry test content. Checks on the built artefact itself, not just on the code, catch these.
Related terms
Sources
Planning a product and not sure where release management fits? Ask us, or browse all 116 terms in the glossary.