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.
Files changed (2) hide show
  1. package/docs/ci.md +31 -14
  2. 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 `develop` dist-tag.
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 `develop` dist-tag. The version has no `-beta` suffix, but
154
- normal `npm install hikoutei` still resolves `latest` rather than this channel.
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@develop
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`. After a stable main release, merge
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. Normal users install the stable channel with:
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
- `develop`/`latest` dist-tags, and the stale branch SHA checks are enforced by
255
+ `latest` dist-tag, and the stale branch SHA checks are enforced by
239
256
  the corresponding workflows.
240
257
 
241
258
  ## Action versions
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "hikoutei",
3
- "version": "0.3.3",
3
+ "version": "0.3.4",
4
4
  "description": "Hikoutei — typed repository and safe write layer for Google Sheets-backed MVPs.",
5
5
  "repository": {
6
6
  "type": "git",