-
Notifications
You must be signed in to change notification settings - Fork 0
Versioning and Releases
PumpSync uses component-owned Semantic Versioning for the iOS app and backend. The app and backend begin at 1.0.0 but advance independently. The public website and this wiki are not versioned components.
Stable component versions use MAJOR.MINOR.PATCH with no omitted components, leading zeroes, prerelease suffix, or build metadata.
- Increment PATCH for backward-compatible fixes.
- Increment MINOR for backward-compatible functionality.
- Increment MAJOR for breaking public behavior or interfaces.
Git tags add a v prefix, such as v1.0.0. Container release tags use the numeric form, such as 1.0.0.
The /api/v1 route is an API compatibility generation, not the backend product version. It changes only when the HTTP contract needs a new incompatible route generation.
MARKETING_VERSION in project.yml is authoritative and must contain all three SemVer components. CFBundleVersion is a separate monotonically increasing App Store Connect build number.
Successive TestFlight candidates for one intended release keep the same marketing version and increment only the build number. For example, 1.0.0 (2), 1.0.0 (3), and 1.0.0 (4) are different candidates for the same eventual App Store release. App Store Connect and the source commit SHA provide candidate traceability; TestFlight builds do not receive Git tags.
Build 7 is the protocol 3 migration candidate for marketing version 1.0.0; it does not change MARKETING_VERSION. Deploy and validate the compatible backend before distributing the build. A Build 7 candidate is not ready for testers until nonproduction capabilities reports protocol 3, physical-device hosted enrollment and renewal pass, self-hosted Apple independence is confirmed, and the public/App Store privacy disclosures include App Attest receipt and risk-outcome handling.
After Apple accepts the final production build, create v1.0.0 on that build's exact source commit and publish one GitHub Release. Never move the stable tag. After 1.0.0 is public, any changed app release advances to 1.0.1, 1.1.0, or 2.0.0 according to the change.
VersionPrefix in Directory.Build.props is authoritative for backend assemblies, tools, the capabilities response, and OCI image metadata. /api/v1/capabilities returns the deployed component version as serviceVersion.
Unreleased and nonproduction images use immutable commit-SHA tags. A matching stable backend Git tag publishes the same image content under its numeric SemVer tag. The hosted and self-host/demo images carry both org.opencontainers.image.version and org.opencontainers.image.revision labels.
Container Apps deploy immutable SHA tags or digests even when a human-readable SemVer alias exists. latest, prod-latest, and nonprod-latest are convenience pointers and are never deployment evidence. latest moves only for a stable release; unreleased main builds do not change it.
The backend v1.0.0 tag and GitHub Release may be created before or after the app's v1.0.0 because the components have independent release schedules. A released Git tag or container SemVer tag must never be repointed at different content.
Before creating a stable tag, verify the worktree is clean, HEAD matches its upstream, and the tag is absent locally and remotely. Run the component's complete tests and release checks, then record the source commit, build number where applicable, container digest, and deployed image revision in the release evidence.
If a release candidate changes before production acceptance, keep the intended SemVer version and create a new TestFlight build or backend SHA artifact. Create the stable tag only when that component's production artifact is final.
PumpSync documentation: iOS repository · Backend repository · Issues