murashit_codex-panel/docs/release.md

28 lines
2.4 KiB
Markdown
Raw Normal View History

2026-05-16 11:16:10 +00:00
# Release
GitHub Releases attach only `main.js`, `manifest.json`, and `styles.css` as Obsidian install assets. `LICENSE` and `NOTICE` are kept in the repository and source archives for license distribution.
2026-05-20 05:12:19 +00:00
Release work is Jujutsu-first in a colocated Git repository; Git is still used to push the tag that triggers the GitHub Release workflow. If the checkout has not been initialized for Jujutsu yet, run `jj git init --colocate` and `jj bookmark track main --remote=origin` once.
2026-06-19 11:35:28 +00:00
Plugin versions use SemVer-shaped numbers for Obsidian distribution, but they are not a library API compatibility contract. Prefer patch releases for fixes, dependency updates, internal changes, and compatibility refreshes that preserve existing workflows. Prefer minor releases for user-visible capabilities, settings, workflow additions, or supported-runtime baseline changes. Reserve major releases for disruptive workflow, settings, storage, or support-policy changes.
2026-05-16 11:16:10 +00:00
Create a release by preparing the next version, editing the generated release notes, committing the release changes, then running the preflight before pushing the matching tag:
```sh
npm run release:prepare -- X.Y.Z
# Edit .github/release-notes/X.Y.Z.md.
2026-05-20 05:12:19 +00:00
jj status
jj commit -m "Bump version to X.Y.Z"
jj bookmark move main --to @-
2026-05-16 11:16:10 +00:00
npm run release:preflight
2026-05-20 05:12:19 +00:00
jj tag set X.Y.Z -r main
jj git push --remote origin --bookmark main
git push origin X.Y.Z
2026-05-16 11:16:10 +00:00
```
2026-06-20 00:18:17 +00:00
`release:prepare` updates the version files and creates a `## Changes` release notes template. `release:preflight` verifies the local Jujutsu/Git state, release metadata, API baselines, lockfile, and the same non-cached `npm run check:ci` validation used by CI after the release commit is on `main`.
2026-05-16 11:16:10 +00:00
2026-06-19 00:57:32 +00:00
Release notes should normally include only user-facing changes. Internal implementation changes, validation details, and release procedure notes should be omitted when minor; when they are important enough to mention, group them into at most one concise bullet.
The release workflow runs `npm ci`, `npm run release:check`, `npm run check:ci`, attaches the install assets, and generates GitHub artifact attestations for them. The release notes file is required and must contain a single `## Changes` section. If a tag-triggered release fails before creating the GitHub Release, fix the commit, move the local tag with `jj tag set --allow-move -r main X.Y.Z`, then update the remote tag with `git push --force origin X.Y.Z`.