Versioning

Use one product release version across the app and a monotonic build number for each store artifact. Also retain the exact Git revision and build inputs so support can identify the running bytes.

Identity	Purpose	Example
Product version	Human-facing release	2.4.0
Platform build number	Store/sideload ordering	24017
Git revision	Exact source	a1b2c3d
Environment and app profile	Resolved behavior	prod, brand-b
Artifact checksum	Exact released bytes	SHA-256

Platform Sources

In the current sample-project layout:

• Roku reads major_version, minor_version, and build_version from platforms/roku/src/manifest.
• iOS and Apple TV read MARKETING_VERSION and CURRENT_PROJECT_VERSION from their files under platforms/native/apple/.
• Android and Android TV read android.versionName and android.versionCode from platforms/native/android/app.properties.
• Web has no store-defined build number; expose a project-owned release record in the static artifact if support needs runtime identification.

The shared package.json version may identify the repository or sample rather than a customer release. Do not make it the product version unless the project explicitly defines that contract.

Runtime Build Identity

If the app exposes version information in a support screen or logs, generate one sanitized runtime file during the release build. Include only non-secret data such as product version, build number, Git revision, environment, app profile, and build timestamp.

assets/meta/build-info.json is a reasonable project convention, not a Hosanna-required filename. Add it to each target’s asset-copy rules and test that production packages include the intended file.

Release Rules

1. Allocate product and platform versions before building.
2. Stamp every platform from the same release record.
3. Build and test immutable artifacts.
4. Record checksums, config-source manifest, and toolchain versions.
5. Tag the source only when the tested artifacts are accepted.
6. Never reuse a platform build number for different bytes.