# Memorains Github Release > Tag a new version, create a GitHub release with organized release notes, build all packages, and upload artifacts. Use when the user wants to release, tag, publish, or ship a new version of memorains on GitHub, or mentions putting out a GitHub release. Use when this capability is needed. - Skill: `tomevault-io/memorains-github-release` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/memorains-github-release` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/memorains-github-release/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/memorains-github-release --- # Memorains GitHub Release Create a GitHub release for memorains: tag the version, write release notes by reviewing actual code changes, build all platform packages, and upload them as release assets. ## Prerequisites - `gh` CLI must be installed and authenticated (`gh auth status`) - Working Node.js and npm setup in `client/` and `server/` - Android SDK configured (for `.apk` builds) - `script/build_all.sh` must be runnable ## Release Steps Execute these in order. Wait for each step to complete before starting the next. ### 1. Determine the version and last release Read the current version from `client/package.json` — this is the version to release: ```bash node -e "console.log(JSON.parse(require('fs').readFileSync('client/package.json')).version)" ``` Then find the **latest published GitHub release** — this is the baseline for "what changed": ```bash gh release list --limit 5 ``` Use the top entry as the last release. If the user mentions a specific prior release (e.g., "since 0.8.68"), prefer that instead. Release notes should cover all commits since that release tag: ```bash git log ..HEAD --oneline --no-decorate ``` ### 2. Review commits since the last release Get the full list of commits between the last release tag and HEAD: ```bash git log ..HEAD --oneline --no-decorate ``` Then, **read the actual code diffs** — not just commit messages. For each major feature/fix area, inspect the relevant files: ```bash # Get the list of files that changed git diff --stat ..HEAD # Read diffs for key areas (group by component/feature) git diff ..HEAD -- ``` Pay special attention to: - New files (new features) - `client/src/components/` — UI components - `client/src/editor/` — editor logic - `client/src/utils/` — utilities - `client/src/internationnalization/` — new i18n strings ### 3. Write organized release notes Group changes by category, not by commit. Use sections like: - **New Features** — brand new capabilities - **Improvements** — enhancements to existing features - **UI** — visual/presentation changes - **Bug Fixes** — problems resolved For each item, write a one-line summary describing what changed from the user's perspective. Include keyboard shortcuts, file paths, or UI positions when relevant. Be specific — prefer "Outline panel with hierarchical tree view, collapsible by heading level" over "added outline". Write notes to a temp file to avoid shell escaping issues: ```bash # Write to /tmp/release-notes-.md first, then use --notes-file gh release create --title "v" --notes-file /tmp/release-notes-.md ``` ### 4. Create and push the tag ```bash git tag -a -m ": " git push origin ``` ### 5. Create the GitHub release ```bash gh release create \ --title "v" \ --notes-file /tmp/release-notes-.md ``` Verify the release body afterward: ```bash gh release view --json body | python3 -m json.tool | head -20 ``` If the body is truncated (shows only a heading), the notes file content wasn't passed correctly. Re-edit the release: ```bash gh release edit --notes-file /tmp/release-notes-.md ``` ### 6. Build all packages Run from the `script/` directory: ```bash cd /script && bash build_all.sh ``` This produces: - `script/out/package.tar.gz` — web deploy package (Docker) - `script/out/memorains-note__amd64.deb` — Linux desktop - `script/out/memorains-note-win32-x64-.zip` — Windows desktop - `script/out/memorains-release.apk` — Android (signed) ### 7. Upload artifacts to the release ```bash cd /script/out && \ gh release upload \ memorains-note__amd64.deb \ memorains-note-win32-x64-.zip \ memorains-release.apk \ package.tar.gz \ --clobber ``` Verify with: ```bash gh release view --json assets --jq '.assets[] | "\(.name) \(.size | tonumber / 1048576 * 100 | floor / 100)MB"' ``` ### 8. Bump version for next development cycle After the release, bump the patch version in `client/package.json` so the next changes start from a fresh version. **Do not commit or push** — the user will do that when they start the next round of changes. ## Example Release Notes Structure ```markdown ## What's New in v ### ✨ New Features - Item one - Item two ### 🔄 Improvements - Item one ### ⌨️ Keyboard Shortcuts - **Shortcut** — description ### 🎨 UI Improvements - Item one ### 🐛 Bug Fixes - **Bold summary** — detail about the fix --- _N commits since v_ | _Co-authored-by: pi_ ``` Keep notes concise but specific. Every item should tell the reader what changed and why it matters. Avoid vague summaries and group related commits into single bullet points. --- > Source: [redTreeOnWall/memorains](https://github.com/redTreeOnWall/memorains) — distributed by [TomeVault](https://tomevault.io).