[SSW-3179] Expose versionLabel on packages from update_check

[miklosboros]

SSW-3179

Summary

A customer reported that the only release identifier the SDK exposes, label, holds the update's UUID, while the Bitrise UI and CLI call the same update v1, v2, and so on. The CodePush service is adding a version_label field to update_check with that value (service PR linked below). This PR passes it through to apps as versionLabel on RemotePackage and LocalPackage, so an app can show or report which release its users are running.

Changes

• The acquisition SDK maps version_label from the update_check response to versionLabel on the remote package, next to label.
• versionLabel is an optional string in the public typings, with the API docs and the API compatibility check updated. It is optional because packages downloaded by an older SDK were persisted without it.
• The label docs no longer say the value looks like v5. On Bitrise it is the update's UUID, and that mismatch is what prompted the customer report.
• The E2E mock server returns version_label. The checkForUpdate test asserts it reaches the app, and the download test asserts it is still on the package read back from native storage.

Why there are no native changes

iOS and Android persist the whole package object to app.json and hand it back from getUpdateMetadata, the sync status report, and the native getCurrentPackage accessors. The new property reaches native code the same way label does, with no per-field plumbing.

Notes for reviewers

• Against a service that does not send the field yet, apps get versionLabel: undefined. The bridge and both native JSON layers already accept that, as they do for a missing description.
• label is unchanged on purpose. The SDK sends it back on status reports and on the next update_check, and the service expects the UUID there.
• This needs an SDK release once the service change is live. The customer is on @bitrise/code-push-sdk 10.5.6.

Service side: https://github.com/bitrise-io/release-management-code-push-service/pull/258

[Copilot]

Copilot review overview

🟡 Changes recommended

The mock typing must remain optional, and local-package persistence needs E2E coverage before approval.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1

Open (1)

• Update checkForUpdate docs to distinguish label and versionLabel · New

What changed in this PR

Exposes the service’s human-readable version_label as optional versionLabel package metadata while preserving the UUID-based label.

Changes:

• Maps version_label through the acquisition SDK.
• Updates public typings, documentation, and API compatibility checks.
• Extends mocks and test expectations.

File	Description
typings/​react-native-code-push.d.ts	Adds public versionLabel typing.
test/​test.ts	Verifies remote-package propagation; local-package persistence coverage remains needed.
src/​acquisition-sdk/​types.ts	Types the service response field.
src/​acquisition-sdk/​acquisition-sdk.ts	Maps the field to packages; its nullability comment needs correction.
src/​acquisition-sdk/​__tests__/​acquisition-sdk.test.ts	Updates SDK expectations.
src/​acquisition-sdk/​__tests__/​acquisition-rest-mock.ts	Adds mock response data.
docs/​api-js.md	Documents label semantics; one conflicting example remains.
code-push-plugin-testing-framework/​typings/​code-push-plugin-testing-framework.d.ts	Types the mock field, but incorrectly requires it.
code-push-plugin-testing-framework/​script/​serverUtil.js	Populates mock version labels.
api-compat/​compat.ts	Covers the additive public API.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.