Skip to content

RELEASING.md

Latest commit

 

History

History
59 lines (42 loc) · 2.39 KB

RELEASING.md

File metadata and controls

59 lines (42 loc) · 2.39 KB

Releasing OpenLess

This document defines who may cut releases and how. It is policy, not a how-to for day-to-day development.

Authority: admins only

Only repository administrators may create version tags and publish releases.

  • Only an admin may create a release tag (v*-tauri) or publish a GitHub Release.
  • Contributors (including AI agents) must not create release tags, publish releases, or trigger release automation. If a release is needed, request an admin to cut it — open an issue or ping a maintainer with the target version and the channel (Beta or Stable).
  • Release automation (CI workflows that build, sign, and publish artifacts, and the auto-updater feed) must be admin-triggered only. Tag-triggered pipelines are considered admin-triggered because only admins may push the triggering tag.

Channels and tags

Two channels; the branch name equals the channel name:

  • beta — default development branch and the Beta channel.
  • main — the Stable channel (正式版). Always releasable; only maintainers merge beta → main.

Release tags (created by an admin only):

  • Stable release: push tag v<version>-tauri.
  • Beta release: push tag v<version>-beta-tauri (published as a GitHub pre-release; never auto-updates Stable users).

Version-sync gate

A release fails CI unless five files carry the same version. Bump them together with 1-app/scripts/bump-version.sh <X.Y.Z>:

  • openless-all/app/package.json
  • openless-all/app/package-lock.json (root and nested packages."")
  • openless-all/app/src-tauri/tauri.conf.json
  • openless-all/app/src-tauri/Cargo.toml
  • openless-all/app/src-tauri/Cargo.lock (the name = "openless" block)

The script takes a plain X.Y.Z; for a -beta suffix, edit the files by hand.

Pre-release checklist (for the admin cutting the release)

  1. Branch is the intended channel (beta for Beta, main for Stable).
  2. All five version files match (version-sync gate green).
  3. CI is green on the commit being tagged.
  4. Then, and only then, push the release tag.

Process summary

  1. Land work on beta via PRs (open PRs against beta, never main).
  2. For a Stable release, a maintainer merges beta → main.
  3. An admin bumps the version (five-file sync), verifies CI is green, and pushes the release tag — which is the only thing that triggers the publish/auto-update pipeline.