Peak POS SDK release checklist

Use this checklist for libs/sdks/kotlin/peak-pos-sdk. Separate local verification from publication: Bazel builds/tests are non-publishing; .github/workflows/sdk-publish.yml owns registry and GitHub release side effects.

1. Define the release version

The publish workflow resolves one SDK version from either:

• the required version input on a manual dispatch; or
• a published release tag such as v1.2.3 or sdk/v1.2.3.

The accepted value is SemVer-shaped: MAJOR.MINOR.PATCH with an optional suffix. Do not edit the KMP rule's checked-in build_version = "0.1.0" or the template POM versions merely to publish a release. The workflow builds version-neutral artifacts and rewrites the published POMs and asset filenames with the resolved release version.

Record the intended version once and use it for every platform artifact and consumer check.

2. Verify source and contract tests

Run the SDK package tests and the cross-SDK artifact/contract tests:

bazel test --build_tests_only //libs/sdks/kotlin/peak-pos-sdk:all
bazel test \
  //libs/sdks:generated_sdk_contract_drift_test \
  //libs/sdks:kmp_xcframework_artifact_contract_test

If checked-in OpenAPI inputs changed, regenerate through the repository's approved generator change before this checklist; do not hand-edit generated SDK models to make drift tests pass.

3. Build the Linux/JVM and Android release handoff

The workflow's BuildBuddy runner builds this stable release bundle:

bazel build //libs/sdks/kotlin/peak-pos-sdk:peak_pos_sdk_kmp_jvm_android_release_bundle

The target packages the version-neutral outputs from:

• //libs/sdks/kotlin/peak-pos-sdk:peak_pos_sdk_kmp_jvm_jar as peak-pos-sdk.jar;
• //libs/sdks/kotlin/peak-pos-sdk:peak_pos_sdk_kmp_android_aar as peak-pos-sdk-android.aar.

Build the primary Android consumer through the Android wrapper:

scripts/bazel-android.sh build //apps/android:android_app_local_staging

Run any focused app tests covering the changed SDK behavior. A successful SDK jar/AAR build alone does not prove the consuming APK resolves, dexes, or preserves the intended runtime behavior.

4. Verify static consumer lanes

Run the repository-owned consumer contracts:

bazel test \
  //apps/ios:peak_pos_client_lane_test \
  //apps/mobile:peak_mobile_lane_test \
  //apps/mobile:peak_mobile_android_boundary_test

These targets prove checked-in lane and boundary contracts. They do not replace a native Apple build, Android installation, or device smoke when the change depends on platform behavior.

5. Build Apple artifacts on macOS

Only a Mac/Xcode host can produce the Kotlin/Native Apple artifact. On that host run:

bazel build --config=macos \
  //libs/sdks/kotlin/peak-pos-sdk:peak_pos_sdk_kmp_xcframework_zip \
  //libs/sdks/kotlin/peak-pos-sdk:peak_pos_sdk_kmp_spm_checksum

Confirm the checksum target was produced from the exact XCFramework zip. The Linux/static lane can report this gate as unavailable, but cannot mark it passing. The publish workflow runs the Apple job only when repository variable IOS_CI_ENABLED is true.

6. Check Gateway dependency pins when the change touches payments

Peak POS SDK release versioning is independent of the Gateway SDK dependency pins in MODULE.bazel:

• GATEWAY_SDK_CORE_VERSION selects gateway-sdk-core-kmp;
• GATEWAY_SDK_VERSION selects gateway-sdk-android and gateway-sdk-android-nearpay;
• GATEWAY_SDK_IOS_VERSION selects the Apple Gateway artifact.

When one of those inputs changes, update MODULE.bazel.lock through normal Bazel resolution and build the Android import smoke:

bazel build //apps/android/app/src/main:gateway_sdk_smoke

The bare build intentionally omits an Android configuration: this target is a library-only import smoke and does not build or install an APK.

scripts/verify-gateway-sdk-release.sh currently accepts an Android/KMP version and an iOS version and checks gateway-sdk-core-kmp at the Android version. It does not read the independent GATEWAY_SDK_CORE_VERSION pin. Do not cite that script as complete proof when the core and Android versions differ; use Bazel consumer resolution plus the Gateway release assets and the Gateway iOS SDK Smoke workflow for the independently pinned artifacts.

7. Run the publish workflow in dry-run mode

Dispatch .github/workflows/sdk-publish.yml (Publish SDKs) with:

• version: the reviewed SemVer value;
• dry_run: true (the manual default).

The workflow still uses authenticated runners and uploads GitHub Actions workflow artifacts, but dry-run mode does not upload Peak POS SDK files to Artifact Registry Maven or attach them to a GitHub release. Review both platform jobs and download their workflow artifacts.

Expected Peak POS SDK release files are:

Platform	Files
JVM	peak-pos-sdk-<version>.jar, peak-pos-sdk-<version>.pom
Android	peak-pos-sdk-android-<version>.aar, peak-pos-sdk-android-<version>.pom
Apple	PeakPosSdk-<version>.xcframework.zip, PeakPosSdk-<version>.spm.checksum

Confirm every file is non-empty, every filename has the same version, the POM coordinates are under com.myriad.peakpos, and the Apple checksum matches the exact zip. If the Apple job is disabled or skipped, the release is missing Apple proof; record that boundary rather than silently treating the Linux artifacts as complete.

8. Publish only from the approved release lane

Publication is a side effect. Before changing dry_run to false or publishing a GitHub release, require:

• all applicable tests and consumers above are green;
• dry-run artifacts were inspected;
• the version is final and not already present in the target repository;
• registry, release, and rollback ownership are assigned;
• platform-specific unavailable gates are resolved or explicitly accepted by the release owner.

A manual run with dry_run=false uploads Maven/other configured registry artifacts. A published GitHub release triggers the entire Publish SDKs workflow, including the configured JavaScript, Java, Peak POS JVM/Android, and (when enabled) Apple SDK jobs; it is not a Peak-POS-only switch. The release event also attaches Peak POS artifacts to that release.

Do not publish with direct curl, Gradle, Maven, or local registry commands. Do not overwrite an existing version. Preserve workflow and BuildBuddy invocation links as release evidence.

9. Post-publication verification

After the authorized workflow succeeds:

1. verify com.myriad.peakpos:peak-pos-sdk:<version> and com.myriad.peakpos:peak-pos-sdk-android:<version> contain both artifact and POM;
2. verify the expected GitHub release assets exist for the event-driven lane;
3. resolve the released coordinates from an approved consumer lane without modifying production;
4. repeat the focused consumer build/test that motivated the release;
5. record the immutable version, checksums, workflow run, BuildBuddy invocation, and any platform exception.

Signing, store upload, production deployment, and payment movement are separate authorized operations and are not implied by SDK publication.