Skip to main content

Versioning

Release versions​

V3 releases are 3.0.0-pre.N while the line is pre-release. One ProjectV release stamps all six owned packages and their mutual dependencies with the same version. The ten shared CrossSDK packages retain the versions pinned in the accepted dependency lock; a ProjectV version bump does not restamp them. The Client consumes that exact approved package set.

Deliveries are immutable: a published package path and its commit never change. A fix is a new release (pre.N+1) and a new delivery.

Contract revisions​

The backend contract has a major.minor revision (git tag contract/<major>.<minor> on projectz-nakama, for example contract/3.2). Admission admits a server of the same major whose minor is at least the client's. Therefore:

  • additive server changes (new optional fields, new operations, new enum values) need a minor bump and keep released clients working;
  • breaking changes need a new major and a matching Client release;
  • deploy the server before, or together with, a Client that needs a newer minor.

Pre-release API changes​

Pre-release builds may break the public API (for example the ID → Id rename). Each breaking change is called out in the package CHANGELOG.md and the Presenter reference is updated in the same change. No compatibility aliases are kept.

Before and after a delivery​

Before: package IDs and versions, candidate identity, Run1/Run2 equality, profile acceptance, and the approved scope. After: VERIFIED_COMPLETE from publish-sdk.yml, Client resolve from Git at the package revision, and the full local flow on the Client.