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: docs-site/docs/project/release-channels.mdx
+34-17Lines changed: 34 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,44 +1,61 @@
1
1
---
2
2
title: Release channels
3
-
description: Alpha and stable release pipeline policy.
3
+
description: Stable and prerelease pipeline policy.
4
4
---
5
5
6
6
# Release channels
7
7
8
-
The package publishes alpha builds from `next` and stable builds from `main`.
8
+
The public install path uses npm `latest`.
9
9
10
10
```sh
11
-
npm install @crup/react-timer-hook@alpha
11
+
npm install @crup/react-timer-hook@latest
12
12
```
13
13
14
-
-`Prerelease` publishes an `0.0.1-alpha.x` version from `next`.
15
-
-`Prerelease` updates the `alpha` dist-tag.
16
-
- Npm requires a `latest` dist-tag, so the workflow keeps `latest` pointing at the current alpha until stable publishing is unlocked.
17
-
-`Release` only runs from `main`.
18
-
-`Release` is manually gated and requires `confirm_stable_release=publish-stable`.
19
-
- The first stable version should be `0.0.1` to match the existing `0.0.1-alpha.x` prerelease line.
14
+
Stable releases are cut from `main`. Prerelease builds can still be published from `next` for testing, but the docs and README should point users at `latest` once stable publishing is enabled.
20
15
21
16
## Stable release stages
22
17
23
-
The stable release workflow is intentionally split into visible jobs:
18
+
The `Release` workflow is intentionally split into visible jobs:
24
19
25
20
| Stage | What it gates |
26
21
| --- | --- |
27
-
|Release guard| Confirms the workflow is running on `main`, the stable confirmation was typed, and the version is stable semver. |
22
+
|Plan release| Confirms the workflow is running on `main`, validates the publish gate, and resolves the release version. |
| Publish npm latest | Sets the stable version, blocks duplicate publishes, builds the final package, and publishes to npm `latest`. |
30
25
| Create GitHub release | Creates a `vX.Y.Z` GitHub release for the exact `main` commit. |
31
26
32
-
Recommended flow:
27
+
## Stable release inputs
28
+
29
+
| Input | Type | Use |
30
+
| --- | --- | --- |
31
+
|`confirm_stable_release`| Dropdown | Choose `publish-stable` to unlock npm `latest`. Leave `locked` to block publishing. |
32
+
|`version_bump`| Dropdown | Choose `patch`, `minor`, `major`, or `manual`. `patch` is the normal OSS default. |
33
+
|`stable_version`| Text | Only used when `version_bump` is `manual`. |
34
+
35
+
The first stable version resolves to `0.0.1` because the prerelease line already used the `0.0.1` base.
36
+
37
+
After a stable version exists, `patch` resolves the next patch automatically. For example, if npm `latest` is `0.0.1`, the next patch release resolves to `0.0.2`.
38
+
39
+
Use this rule of thumb:
40
+
41
+
| Change type | Release action |
42
+
| --- | --- |
43
+
| Documentation, CI-only, internal chore | Usually do not publish a stable npm release. Merge to `main` only. |
44
+
| Backward-compatible bug fix | Publish a patch release. |
45
+
| Backward-compatible feature | Publish a minor release. |
46
+
| Breaking API change | Publish a major release. |
47
+
48
+
## Recommended flow
33
49
34
50
1. Merge feature work into `next`.
35
-
2. Test alpha from `next`.
51
+
2. Test a prerelease from `next` when needed.
36
52
3. Open and merge `next` into `main`.
37
-
4. Run `Release` manually on `main` with:
53
+
4. Run `Release` manually on `main`.
54
+
55
+
For the first stable release, use:
38
56
39
57
```txt
40
58
confirm_stable_release=publish-stable
41
-
stable_version=0.0.1
59
+
version_bump=patch
60
+
stable_version=
42
61
```
43
-
44
-
Consumers should use `@alpha` until the stable workflow has published `latest`.
0 commit comments