hikoutei 0.3.3 → 0.3.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/ci.md +31 -14
- package/package.json +1 -1
package/docs/ci.md
CHANGED
|
@@ -78,11 +78,11 @@ credentials); the root API smoke is local-only, an in-memory SQLite authority
|
|
|
78
78
|
- `.github/workflows/develop-version.yml` creates the next patch version and
|
|
79
79
|
`develop-vX.Y.Z` tag after a `develop` push.
|
|
80
80
|
- `.github/workflows/develop-publish.yml` verifies and publishes that tag with
|
|
81
|
-
the `
|
|
81
|
+
the `latest` dist-tag.
|
|
82
82
|
- `.github/workflows/main-version.yml` creates the next minor version and
|
|
83
83
|
`vX.Y.Z` tag after a `main` push.
|
|
84
84
|
- `.github/workflows/stable-publish.yml` verifies and publishes that tag with
|
|
85
|
-
the `latest` dist-tag.
|
|
85
|
+
the `latest` dist-tag too.
|
|
86
86
|
|
|
87
87
|
Only the internal sync/gateway E2E has a live variant, in the separate
|
|
88
88
|
`.github/workflows/live-integration.yml` workflow. It is opt-in via
|
|
@@ -150,23 +150,24 @@ being processed as another release.
|
|
|
150
150
|
The tag triggers `.github/workflows/develop-publish.yml`. It repeats the
|
|
151
151
|
unit/type/build/package checks, the installed-package internal sync/gateway
|
|
152
152
|
E2E, and the installed root API smoke before publishing the numeric package
|
|
153
|
-
version with the npm `
|
|
154
|
-
|
|
155
|
-
Install the develop channel explicitly:
|
|
153
|
+
version with the npm `latest` dist-tag. The version has no `-beta` suffix, and
|
|
154
|
+
a plain `npm install hikoutei` resolves this channel:
|
|
156
155
|
|
|
157
156
|
```sh
|
|
158
|
-
npm install hikoutei
|
|
157
|
+
npm install hikoutei
|
|
159
158
|
```
|
|
160
159
|
|
|
160
|
+
The old `develop` dist-tag is no longer updated by this workflow; existing
|
|
161
|
+
pinned `hikoutei@develop` installs keep the last develop-tagged version.
|
|
162
|
+
|
|
161
163
|
The version calculation is isolated in `scripts/ci/release-version.mjs` and is
|
|
162
164
|
covered by `test/release-version.test.ts`. For example:
|
|
163
165
|
|
|
164
166
|
```text
|
|
165
167
|
0.3.0 + patch → 0.3.1
|
|
166
168
|
0.3.1 + patch → 0.3.2
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
The workflow requires a repository `RELEASE_TOKEN` secret with contents write
|
|
169
|
+
0.3.2 + patch → 0.3.3
|
|
170
|
+
```The workflow requires a repository `RELEASE_TOKEN` secret with contents write
|
|
170
171
|
permission. A token other than the default `GITHUB_TOKEN` is used because a
|
|
171
172
|
push made by `GITHUB_TOKEN` does not trigger another workflow; the release tag
|
|
172
173
|
must trigger `develop-publish.yml`. The publish job separately requires
|
|
@@ -196,11 +197,27 @@ workflow.
|
|
|
196
197
|
The main version workflow uses the same `RELEASE_TOKEN` requirement so its
|
|
197
198
|
`vX.Y.Z` tag triggers `stable-publish.yml`. The stable publish job also
|
|
198
199
|
requires the repository `NPM_TOKEN` secret and npm provenance before publishing
|
|
199
|
-
`latest`.
|
|
200
|
-
`main` back into `develop` so the next patch release starts from the new stable
|
|
201
|
-
baseline. Stable package versions are
|
|
200
|
+
`latest`. Stable package versions are
|
|
202
201
|
immutable on npm, so reusing a published version fails instead of replacing
|
|
203
|
-
it.
|
|
202
|
+
it.
|
|
203
|
+
|
|
204
|
+
Both channels publish `latest`, so their versions must increase globally:
|
|
205
|
+
|
|
206
|
+
```text
|
|
207
|
+
develop merges → patch: 0.3.3 → 0.3.4 → 0.3.5 (latest)
|
|
208
|
+
main merge (after merging develop) → minor: 0.3.5 → 0.4.0 (latest)
|
|
209
|
+
merge main back into develop → 0.4.0
|
|
210
|
+
next develop merges → patch: 0.4.0 → 0.4.1 → 0.4.2 (latest)
|
|
211
|
+
next main merge → minor: 0.4.2 → 0.5.0 (latest)
|
|
212
|
+
```
|
|
213
|
+
|
|
214
|
+
Keep the channels aligned: after a stable main release, merge `main` back
|
|
215
|
+
into `develop` so the next develop patch release starts from the new stable
|
|
216
|
+
baseline. If a develop release is prepared before that back-merge, its
|
|
217
|
+
publish fails loudly on the latest-dist-tag monotonicity check (the develop
|
|
218
|
+
version trails the main minor); merge main back and re-run the publish from
|
|
219
|
+
the existing `develop-vX.Y.Z` tag. Normal users install the rolling line
|
|
220
|
+
with:
|
|
204
221
|
|
|
205
222
|
```sh
|
|
206
223
|
npm install hikoutei
|
|
@@ -235,7 +252,7 @@ package directory, asserts it contains exactly one `hikoutei-*.tgz` and the
|
|
|
235
252
|
checksum file, verifies the checksum line names that exact tarball (not merely
|
|
236
253
|
any file present in the directory), and only then runs `sha256sum --check`
|
|
237
254
|
before publishing. Name/version validation, npm provenance, the
|
|
238
|
-
`
|
|
255
|
+
`latest` dist-tag, and the stale branch SHA checks are enforced by
|
|
239
256
|
the corresponding workflows.
|
|
240
257
|
|
|
241
258
|
## Action versions
|