@surrealdb/ui 1.2.13 → 1.2.14

package/doc/release.md

@@ -0,0 +1,102 @@
+# Release process
+
+This document describes how to cut a release of `@surrealdb/ui`.
+
+## 1. Determine the version bump
+
+Releases follow [semantic versioning](https://semver.org/) (`x.y.z`).
+
+- **Patch** (`x.y.Z`) — the default. Unless the release is explicitly stated
+  to be a minor or major, always assume it is a patch.
+- **Minor** (`x.Y.0`) — only when explicitly stated (new backwards-compatible
+  features).
+- **Major** (`X.0.0`) — only when explicitly stated (breaking changes).
+
+## 2. Determine the next version
+
+Read the current version from `package.json` (the `version` field) and apply
+the bump from step 1.
+
+For example, if the current version is `1.2.12`:
+
+| Bump  | Next version |
+| ----- | ------------ |
+| patch | `1.2.13`     |
+| minor | `1.3.0`      |
+| major | `2.0.0`      |
+
+The resulting `x.y.z` is used for the branch name, the `package.json` version,
+and the pull request title below.
+
+## 3. Create the release branch
+
+Branch off the latest `main`:
+
+```sh
+git checkout main
+git pull
+git checkout -b release/x.y.z
+```
+
+## 4. Bump the `package.json` version
+
+Set the `version` field in `package.json` to the new `x.y.z`.
+
+## 5. Format, test, and fix
+
+1. Run the formatter and apply any fixes:
+
+    ```sh
+    bun run qa
+    ```
+
+    If this produces changes (formatting that was previously missing), commit
+    them.
+
+2. Run the test suite:
+
+    ```sh
+    bun run test
+    ```
+
+3. Iteratively fix any broken tests, re-running the suite until it passes.
+   Commit the fixes.
+
+## 6. Commit and push
+
+Commit the version bump (and any formatting/test fixes) and push the branch:
+
+```sh
+git push -u origin release/x.y.z
+```
+
+## 7. Open the pull request
+
+Open a pull request from `release/x.y.z` into `main`.
+
+- **Title:** `Release x.y.z`
+- **Description:** a bullet-point list of the PRs included in this release,
+  each linking to its PR. Format each entry as:
+
+    ```md
+    - Did something (#100)
+    ```
+
+    where `#100` links to the corresponding pull request. Compile the list from
+    the PRs merged into `main` since the previous release.
+
+> **The PR description becomes the release notes**, so make sure it is
+> complete and well-formed before merging.
+
+## 8. Merge the pull request
+
+Merging the `release/x.y.z` branch into `main` is all that's required — the
+[Publish workflow](../.github/workflows/publish.yml) takes over automatically:
+
+1. It infers the tag `vx.y.z` from the branch name and asserts it matches the
+   `package.json` version.
+2. It creates the GitHub release, using the PR description as the release notes.
+3. It builds, packs, and publishes the package to npm.
+
+No manual GitHub release or tag is needed. (Publishing a GitHub release by hand
+still works as a fallback — it triggers the same build-and-publish steps.)

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@surrealdb/ui",
-	"version": "1.2.13",
+	"version": "1.2.14",
 	"type": "module",
 	"sideEffects": false,
 	"exports": {
@@ -43,9 +43,7 @@
 		"@codemirror/legacy-modes": "^6.4.2",
 		"@fontsource-variable/geist": "^5.2.9",
 		"@fontsource-variable/jetbrains-mono": "^5.2.8",
-		"@lezer/common": "^1.2.1",
 		"@lezer/go": "^1.0.0",
-		"@lezer/highlight": "^1.2.1",
 		"@lezer/html": "^1.3.10",
 		"@lezer/javascript": "^1.4.17",
 		"@lezer/json": "^1.0.3",
@@ -105,6 +103,9 @@
 		"@codemirror/search": "^6.5.6",
 		"@codemirror/state": "^6.4.1",
 		"@codemirror/view": "^6.24.1",
+		"@lezer/common": "^1.2.1",
+		"@lezer/highlight": "^1.2.1",
+		"@lezer/lr": "^1.4.2",
 		"@mantine/core": "^9.2.2",
 		"@mantine/hooks": "^9.2.2",
 		"mermaid": "^11",