You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: RELEASING.md
+7-1Lines changed: 7 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,6 +27,12 @@ For example:
27
27
28
28
The version must follow `MAJOR.MINOR.PATCH` format (e.g., `0.10.0`, `1.0.0`).
29
29
30
+
By default the script sets the `cli_version` default to match the action version. When the two have drifted — for example, an action-only release while the CLI stays behind — pass the CLI version explicitly:
31
+
32
+
```bash
33
+
./scripts/release.sh 0.14.4 --cli-version 0.14.1
34
+
```
35
+
30
36
## What happens
31
37
32
38
The release script (`scripts/release.sh`) and CI workflows handle the full process:
@@ -68,4 +74,4 @@ The Release workflow then:
68
74
69
75
- Consumers reference this action as `linear/linear-release-action@v0` (the floating major tag), so the major-tag move is the load-bearing step. Without it, consumers stay on whichever commit the major tag previously pointed to.
70
76
- The source of truth for the action's version is [`VERSION`](./VERSION); the auto-tag workflow fails if the branch name and `VERSION` file disagree.
71
-
- The script bumps the `cli_version` default to match the action version. If you need a release where these diverge, edit the release branch by hand before merging the PR — the auto-tag workflow validates the `VERSION` file, not `cli_version`.
77
+
- The script bumps the `cli_version` default to match the action version unless you pass `--cli-version`. The auto-tag workflow validates the `VERSION` file, not `cli_version`, so the two are free to diverge.
0 commit comments