Release and compatibility contract
App/Info.plist CFBundleShortVersionString is the single source of the desktop version. Versions follow Semantic Versioning with the Product Guidelines 0.x compatibility rule: breaking public changes advance minor; additive and corrective ch
Channels#
| Channel | Audience | Coordinate | Current state |
|---|---|---|---|
| Development | Wisent maintainers | Exact source commit | Open |
| Stable | Internal desktop users | Immutable signed app release | Not yet open |
main is moving development source and not a release coordinate. Version 0.2.0 does carry an update check — WisentCheckForUpdatesCommand in the application menu, SUEnableAutomaticChecks enabled, and the appcast at the repository's latest release download — but no immutable signed artifact has been published to that feed yet, so the Stable channel remains closed.
Compatibility#
- macOS 14 or newer, Apple silicon or Intel.
- Swift 6 for source builds.
wisent-desktop-auth0.3.6 for identity and organization selection.wisent-components0.9.1 forWisentDesignSystem, which is the entire presentation layer.wisent-errors1.0.0 for the shared failure report,wisent-desktop-update0.2.0 for the update check, andecho0.3.0 for the first-run journey client.- Skrzynka core
0.2.xexposing authenticated loopback/v1with additive JSON compatibility and database schema 4, which carriesoutbound_messagesand the optional sending-credential reference.
Every dependency is an exact version requirement rather than a revision: wisent-desktop-auth 0.3.6 resolves wisent-components 0.9.1 itself, so the two move together, and Package.resolved records versions. A branch entry, a revision requirement, or a shortened SHA for either URL is a defect.
The desktop client tolerates additive JSON fields through Codable decoding. A breaking core schema requires a new API path or a desktop compatibility release. An unavailable or newer incompatible service must fail visibly rather than reinterpret data. Changing the selected organization clears the previous organization's in-memory resources before the new authenticated workspace is displayed.
Future release artifact#
A stable release must be built from an exact commit in this repository and published here as an immutable, signed, notarized .app archive with version, source revision, macOS/architecture target, SHA-256 digest, build timestamp, and provenance. Publication credentials belong to this repository and remain separate from runtime credentials. Promotion must reuse the same bytes.
Upgrade and rollback#
The app owns no message database or credential migration. Quit the old app and open the exact new artifact. A rollback restores the previous immutable app artifact. An incompatible journey publishes a new immutable journey version ID and leaves prior persisted progress inert rather than reinterpreting it.
Core upgrades and database recovery follow the public Skrzynka release contract. Desktop rollback never rolls back core state.
Release notes#
Every release record must name UI and onboarding changes, API compatibility, supported macOS, persisted-state changes, security-relevant behavior, required core version, operator actions, rollback limits, and known limitations.