Skip to content

T-LH85-polish-release-versioning

Status: closed/obsoleted · Impact: medium · Complexity: medium

The standalone polish repo shipped with release-it + git-cliff for semver and Tauri-bundle releases. The import dropped that tooling (.release-it.json, cliff.toml, commitlint.config.ts), and the monorepo has no polish release path. Decide the monorepo scheme and wire it, so polish can cut versioned, publishable desktop builds.

LocationRole today
apps/legacy-polish/src-tauri/Cargo.tomlapp version 0.1.4; tauri.conf.json version now derives from here (was ../package.json)
dropped: .release-it.json, cliff.toml, commitlint.config.tsstandalone release/changelog/commit tooling, not imported
.github/workflows/release.ymlreleases the SDLC plugin (npm artifact via plugin build-artifact); no polish bundle

A defined, documented scheme for versioning polish and publishing its Tauri bundle within the monorepo, consistent with how dev releases other artifacts.

  1. Decide versioning: tag-scoped (polish-vX.Y.Z) vs a workspace release tool vs changesets. Where does the version of record live (Cargo.toml)?
  2. Decide publish target for the desktop bundle (GitHub Releases? elsewhere).
  3. Wire the release job (likely alongside or modeled on .github/workflows/release.yml); regenerate a changelog if wanted.
LocationKindChange
.github/workflows/newpolish release job (bundle build + publish)
apps/legacy-polish/src-tauri/tauri.conf.jsonmodifyversion source / bundle metadata as needed
  • AC-1: a documented, reproducible command/flow cuts a versioned polish release.
  • AC-2: the produced Tauri bundle is published to the agreed target.
  • Code-signing / notarization (tracked in T-7270).
  • T-7270 — a distributable release generally needs signing.
  • apps/legacy-polish/MIGRATION.md “Owner-gated remainder” item 2 (release / versioning) — deferred at import for a human decision.

← Back to Tasks