version.properties at the repository root is the single source of truth for the VniDrop application version. Platform projects and release workflows read that file rather than accepting independent version overrides.

Keep it as plain KEY=VALUE assignments: the same file is parsed by shell, PowerShell, Gradle, Rust, and Xcode.

The product uses numeric semantic versions. While the app is in beta, feature releases increment the minor component (0.2.0, 0.3.0) and fixes increment the patch component (0.2.1). Release channels belong in RELEASE_CHANNEL; they are not appended to store version fields.

Platform	Product version	Platform build/package version
Android	`PRODUCT_VERSION`	`ANDROID_VERSION_CODE`
Apple	`PRODUCT_VERSION`	`APPLE_BUILD_NUMBER`
Linux and direct macOS	`PRODUCT_VERSION`	Native package revision
Rust handshake	`PRODUCT_VERSION`	Rust crate version remains independent
Microsoft Store	`PRODUCT_VERSION` in the app	Derived MSIX dot-quad

MSIX requires a non-zero first component and reserves the fourth component for the Store. Its version is:

(product major + WINDOWS_VERSION_EPOCH).product minor.product patch.0

With epoch 1, product 0.2.0 maps to MSIX 1.2.0.0, while product 1.0.0 maps to 2.0.0.0. Do not change the epoch after publishing.

Every Android or Apple upload must increment its platform build number. Every changed Windows Store package must increment the product version because the Store-reserved fourth component cannot carry a rebuild number.

Before releasing:

make check-version

Release tags must exactly match vPRODUCT_VERSION. Manual workflow dispatches also build the committed version and do not accept free-form version inputs.