From 7b9029b90d70c8a7763a0b6767865a8ca3e5a947 Mon Sep 17 00:00:00 2001 From: Romain Cascino Date: Wed, 26 Aug 2026 08:59:41 +0200 Subject: [PATCH] Clarify publish-time versioning workflow --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0a8140f..0b96851 100644 --- a/README.md +++ b/README.md @@ -180,7 +180,7 @@ The provider is detected from the remote hostname, or on GitLab CI from the job | `update` | Updates that exact release version | Updates latest started release, or latest planned release if no started release exists | | `complete` | Completes that exact release version | Completes latest started release | -For scheduled pipelines, prefer always passing `--release-version` in CI, especially when releases overlap. Only `sync` sets the version on a release — `complete` and `update` strictly look up by version. If your CI has no natural labeling moment (e.g. tag-driven releases), run `sync --release-version=X` immediately before `complete --release-version=X` at release time. +For scheduled pipelines, prefer always passing `--release-version` in CI, especially when releases overlap. Only `sync` can set the version on a release. If the version is only known when you publish, run `sync --base-ref=HEAD --release-version=X` immediately before `complete --release-version=X`. The `sync` sets `X` on the current unversioned release; `complete` can then mark it complete. ### JSON Output