From ba1f8b88187bc453bfc92ed84aa8ff457444665c Mon Sep 17 00:00:00 2001 From: chen Date: Thu, 30 Jul 2026 16:11:56 +0800 Subject: [PATCH 1/7] docs: add RELEASING.md for the manual tag-and-notes release flow --- RELEASING.md | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 RELEASING.md diff --git a/RELEASING.md b/RELEASING.md new file mode 100644 index 0000000..c7e190c --- /dev/null +++ b/RELEASING.md @@ -0,0 +1,64 @@ +# Releasing + +Manual release flow for **claude-code-chat-browser**. There is **no CI publish workflow**: a release is an annotated git tag plus a GitHub Release with notes. No wheel, npm package, or other artifact is attached. + +`v0.1.0` (2026-06-18) is the only shipped tag so far. `v0.2.0` is in progress and these steps describe how it is being cut. + +## Version source + +The only version string is `__version__` in `app.py` (line 3). There is no `pyproject.toml` version field. + +Between tagged releases, `master` may carry a `.dev0` suffix (for example `0.2.0.dev0` while `0.2.0` was in development). The shipped tag always drops `.dev0`. + +## Pre-release checklist + +1. Confirm `master` is green in GitHub Actions (`.github/workflows/ci.yml`). +2. Decide the semver bump using [docs/deprecation-policy.md](docs/deprecation-policy.md#versioning) (pre-1.0: patch for safe fixes, minor for additive work and deprecations). +3. If the release removes or renames a documented API field, confirm the [two-release deprecation window](docs/deprecation-policy.md#removal-criteria) is satisfied. + +## Release checklist + +Do the changelog in one PR and the version bump in a second PR, or combine them on a `release/vX.Y.Z` branch. The `v0.2.0` cut used two PRs: changelog first (`docs/changelog-0-2-0`), then the bump (`release/v0.2.0`). + +1. **Changelog** — edit [CHANGELOG.md](CHANGELOG.md) ([Keep a Changelog](https://keepachangelog.com/en/1.1.0/)): + - Move everything under `## [Unreleased]` into a new `## [X.Y.Z] - YYYY-MM-DD` section with `### Added`, `### Changed`, `### Fixed`, or `### Removed` as needed. + - Leave `## [Unreleased]` empty. + - Update the footer compare links: `[Unreleased]` → `vX.Y.Z...HEAD`, add `[X.Y.Z]` → `vPREVIOUS...vX.Y.Z`. +2. **Version bump** — on a branch from current `master`, set `app.py` line 3 to the release version without `.dev0` (for example `"0.2.0"`). +3. **Stale references** — from the repo root, grep for the old `.dev0` suffix you are replacing: + ```powershell + git grep -n "\.dev0" + ``` + Update any documentation that still names the previous dev version (for example `docs/deprecation-policy.md`). +4. **Open a PR**, get review, merge to `master`. +5. **Tag** on the merge commit: + ```powershell + git checkout master + git pull + git tag -a vX.Y.Z -m "vX.Y.Z" + git push origin vX.Y.Z + ``` + Tag format: `vMAJOR.MINOR.PATCH` (for example `v0.2.0`). +6. **GitHub Release** — publish a Release object, not just the tag. Copy the `## [X.Y.Z]` section from `CHANGELOG.md` into a scratch file, then: + ```powershell + # paste the ## [X.Y.Z] section into this file first + notepad $env:TEMP\release-notes.md + gh release create vX.Y.Z --title "vX.Y.Z" --notes-file $env:TEMP\release-notes.md + ``` + Or create the release in the GitHub UI and paste the section there. +7. **Optional** — if the project later adds an explicit supported-version table in [SECURITY.md](SECURITY.md), update it when you cut a release. Today `SECURITY.md` only states that fixes land on latest `master`. + +## After release + +1. On `master`, bump `app.py` `__version__` to the next development suffix if you are starting the next cycle (for example `0.3.0.dev0` after shipping `0.2.0`). Record that commit in `CHANGELOG.md` under `[Unreleased]` only if there is user-visible work; a bare dev bump can ride with the next feature PR. +2. New work accumulates under `## [Unreleased]` until the next release. + +## References + +| Topic | Location | +|-------|----------| +| Changelog format | [CHANGELOG.md](CHANGELOG.md) | +| Version bump | `app.py` line 3 | +| Deprecation / semver | [docs/deprecation-policy.md](docs/deprecation-policy.md) | +| Security reporting | [SECURITY.md](SECURITY.md) | +| CI gates | [CONTRIBUTING.md](CONTRIBUTING.md) | From 4263c9eb65a4328e51b5dd6bd6afb3a9bc9d5209 Mon Sep 17 00:00:00 2001 From: chen Date: Thu, 30 Jul 2026 21:56:48 +0800 Subject: [PATCH 2/7] Address feedback --- RELEASING.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index c7e190c..e759dca 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -26,26 +26,30 @@ Do the changelog in one PR and the version bump in a second PR, or combine them - Update the footer compare links: `[Unreleased]` → `vX.Y.Z...HEAD`, add `[X.Y.Z]` → `vPREVIOUS...vX.Y.Z`. 2. **Version bump** — on a branch from current `master`, set `app.py` line 3 to the release version without `.dev0` (for example `"0.2.0"`). 3. **Stale references** — from the repo root, grep for the old `.dev0` suffix you are replacing: - ```powershell + ```sh git grep -n "\.dev0" ``` Update any documentation that still names the previous dev version (for example `docs/deprecation-policy.md`). 4. **Open a PR**, get review, merge to `master`. 5. **Tag** on the merge commit: - ```powershell + ```sh git checkout master git pull git tag -a vX.Y.Z -m "vX.Y.Z" git push origin vX.Y.Z ``` Tag format: `vMAJOR.MINOR.PATCH` (for example `v0.2.0`). -6. **GitHub Release** — publish a Release object, not just the tag. Copy the `## [X.Y.Z]` section from `CHANGELOG.md` into a scratch file, then: - ```powershell - # paste the ## [X.Y.Z] section into this file first - notepad $env:TEMP\release-notes.md - gh release create vX.Y.Z --title "vX.Y.Z" --notes-file $env:TEMP\release-notes.md +6. **GitHub Release** — publish a Release object, not just the tag. Pull the `## [X.Y.Z]` section from `CHANGELOG.md` and pass it to `gh`: + ```sh + VERSION=X.Y.Z + awk -v ver="$VERSION" ' + $0 ~ "^## \\[" ver "\\]" {found=1} + found && $0 ~ "^## \\[" && $0 !~ "^## \\[" ver "\\]" {exit} + found {print} + ' CHANGELOG.md > /tmp/release-notes.md + gh release create "v${VERSION}" --title "v${VERSION}" --notes-file /tmp/release-notes.md ``` - Or create the release in the GitHub UI and paste the section there. + On macOS/Linux and Git Bash, `/tmp/release-notes.md` is fine. Or create the release in the GitHub UI and paste the section there. 7. **Optional** — if the project later adds an explicit supported-version table in [SECURITY.md](SECURITY.md), update it when you cut a release. Today `SECURITY.md` only states that fixes land on latest `master`. ## After release From 10b389493588a9e85d81b59007fef80889546909 Mon Sep 17 00:00:00 2001 From: star-med Date: Fri, 31 Jul 2026 03:16:13 +0800 Subject: [PATCH 3/7] clean up content --- RELEASING.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index e759dca..418b28c 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -1,14 +1,14 @@ # Releasing -Manual release flow for **claude-code-chat-browser**. There is **no CI publish workflow**: a release is an annotated git tag plus a GitHub Release with notes. No wheel, npm package, or other artifact is attached. +Manual release flow for claude-code-chat-browser. A release is an annotated git tag and a GitHub Release with notes. There is no CI publish workflow, and no wheel, npm package, or other artifact is attached. -`v0.1.0` (2026-06-18) is the only shipped tag so far. `v0.2.0` is in progress and these steps describe how it is being cut. +`v0.1.0` (2026-06-18) is the only shipped tag so far. `v0.2.0` is in progress; these steps describe how it is being cut. ## Version source The only version string is `__version__` in `app.py` (line 3). There is no `pyproject.toml` version field. -Between tagged releases, `master` may carry a `.dev0` suffix (for example `0.2.0.dev0` while `0.2.0` was in development). The shipped tag always drops `.dev0`. +Between tagged releases, `master` may carry a `.dev0` suffix (for example `0.2.0.dev0` while `0.2.0` was in development). The shipped tag drops `.dev0`. ## Pre-release checklist @@ -20,18 +20,18 @@ Between tagged releases, `master` may carry a `.dev0` suffix (for example `0.2.0 Do the changelog in one PR and the version bump in a second PR, or combine them on a `release/vX.Y.Z` branch. The `v0.2.0` cut used two PRs: changelog first (`docs/changelog-0-2-0`), then the bump (`release/v0.2.0`). -1. **Changelog** — edit [CHANGELOG.md](CHANGELOG.md) ([Keep a Changelog](https://keepachangelog.com/en/1.1.0/)): +1. Edit [CHANGELOG.md](CHANGELOG.md) ([Keep a Changelog](https://keepachangelog.com/en/1.1.0/)): - Move everything under `## [Unreleased]` into a new `## [X.Y.Z] - YYYY-MM-DD` section with `### Added`, `### Changed`, `### Fixed`, or `### Removed` as needed. - Leave `## [Unreleased]` empty. - Update the footer compare links: `[Unreleased]` → `vX.Y.Z...HEAD`, add `[X.Y.Z]` → `vPREVIOUS...vX.Y.Z`. -2. **Version bump** — on a branch from current `master`, set `app.py` line 3 to the release version without `.dev0` (for example `"0.2.0"`). -3. **Stale references** — from the repo root, grep for the old `.dev0` suffix you are replacing: +2. On a branch from current `master`, set `app.py` line 3 to the release version without `.dev0` (for example `"0.2.0"`). +3. From the repo root, grep for the old `.dev0` suffix you are replacing: ```sh git grep -n "\.dev0" ``` Update any documentation that still names the previous dev version (for example `docs/deprecation-policy.md`). -4. **Open a PR**, get review, merge to `master`. -5. **Tag** on the merge commit: +4. Open a PR, get review, merge to `master`. +5. Tag the merge commit: ```sh git checkout master git pull @@ -39,7 +39,7 @@ Do the changelog in one PR and the version bump in a second PR, or combine them git push origin vX.Y.Z ``` Tag format: `vMAJOR.MINOR.PATCH` (for example `v0.2.0`). -6. **GitHub Release** — publish a Release object, not just the tag. Pull the `## [X.Y.Z]` section from `CHANGELOG.md` and pass it to `gh`: +6. Publish a GitHub Release, not just the tag. Pull the `## [X.Y.Z]` section from `CHANGELOG.md` and pass it to `gh`: ```sh VERSION=X.Y.Z awk -v ver="$VERSION" ' @@ -49,13 +49,13 @@ Do the changelog in one PR and the version bump in a second PR, or combine them ' CHANGELOG.md > /tmp/release-notes.md gh release create "v${VERSION}" --title "v${VERSION}" --notes-file /tmp/release-notes.md ``` - On macOS/Linux and Git Bash, `/tmp/release-notes.md` is fine. Or create the release in the GitHub UI and paste the section there. -7. **Optional** — if the project later adds an explicit supported-version table in [SECURITY.md](SECURITY.md), update it when you cut a release. Today `SECURITY.md` only states that fixes land on latest `master`. + On macOS, Linux, and Git Bash, `/tmp/release-notes.md` works. You can also create the release in the GitHub UI and paste the section there. +7. Optional: if the project later adds a supported-version table in [SECURITY.md](SECURITY.md), update it when you cut a release. `SECURITY.md` today only says fixes land on latest `master`. ## After release -1. On `master`, bump `app.py` `__version__` to the next development suffix if you are starting the next cycle (for example `0.3.0.dev0` after shipping `0.2.0`). Record that commit in `CHANGELOG.md` under `[Unreleased]` only if there is user-visible work; a bare dev bump can ride with the next feature PR. -2. New work accumulates under `## [Unreleased]` until the next release. +1. On `master`, bump `app.py` `__version__` to the next development suffix if you are starting the next cycle (for example `0.3.0.dev0` after shipping `0.2.0`). Put that commit in `CHANGELOG.md` under `[Unreleased]` only when there is user-visible work; a bare dev bump can ride with the next feature PR. +2. New work goes under `## [Unreleased]` until the next release. ## References From d3179667278d691c374fbf4eb75075fddb8b0bfe Mon Sep 17 00:00:00 2001 From: star-med Date: Fri, 31 Jul 2026 05:23:01 +0800 Subject: [PATCH 4/7] docs: harden RELEASING.md with SECURITY sync and guarded release script --- RELEASING.md | 52 +++++++++++++++++++++++++++++++++------------------- 1 file changed, 33 insertions(+), 19 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index 418b28c..3dc71d6 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -1,14 +1,16 @@ # Releasing -Manual release flow for claude-code-chat-browser. A release is an annotated git tag and a GitHub Release with notes. There is no CI publish workflow, and no wheel, npm package, or other artifact is attached. +Manual release flow for claude-code-chat-browser. A release is an annotated git tag plus a GitHub Release with notes. No CI publish workflow, and no wheel, npm package, or other artifact. -`v0.1.0` (2026-06-18) is the only shipped tag so far. `v0.2.0` is in progress; these steps describe how it is being cut. +`v0.1.0` (2026-06-18) is the only shipped tag so far. `v0.2.0` is in progress; these steps describe that cut. ## Version source -The only version string is `__version__` in `app.py` (line 3). There is no `pyproject.toml` version field. +The release version is `__version__` in `app.py` line 3. There is no `pyproject.toml` version field. -Between tagged releases, `master` may carry a `.dev0` suffix (for example `0.2.0.dev0` while `0.2.0` was in development). The shipped tag drops `.dev0`. +`SECURITY.md` line 5 names the version again in the supported-versions blurb (`(currently \`...\`)`). Keep it in sync with `app.py` on every release. `README.md` links to that page for supported versions. + +Between tagged releases, `master` may use a `.dev0` suffix (for example `0.2.0.dev0` while `0.2.0` was in development). The shipped tag drops `.dev0`. ## Pre-release checklist @@ -21,17 +23,18 @@ Between tagged releases, `master` may carry a `.dev0` suffix (for example `0.2.0 Do the changelog in one PR and the version bump in a second PR, or combine them on a `release/vX.Y.Z` branch. The `v0.2.0` cut used two PRs: changelog first (`docs/changelog-0-2-0`), then the bump (`release/v0.2.0`). 1. Edit [CHANGELOG.md](CHANGELOG.md) ([Keep a Changelog](https://keepachangelog.com/en/1.1.0/)): - - Move everything under `## [Unreleased]` into a new `## [X.Y.Z] - YYYY-MM-DD` section with `### Added`, `### Changed`, `### Fixed`, or `### Removed` as needed. + - Move everything under `## [Unreleased]` into a new `## [X.Y.Z] - YYYY-MM-DD` section with `### Added`, `### Changed`, `### Deprecated`, `### Fixed`, `### Removed`, or `### Security` as needed. - Leave `## [Unreleased]` empty. - Update the footer compare links: `[Unreleased]` → `vX.Y.Z...HEAD`, add `[X.Y.Z]` → `vPREVIOUS...vX.Y.Z`. 2. On a branch from current `master`, set `app.py` line 3 to the release version without `.dev0` (for example `"0.2.0"`). -3. From the repo root, grep for the old `.dev0` suffix you are replacing: +3. Update [SECURITY.md](SECURITY.md) line 5 so `(currently \`...\`)` matches that version (for example `(currently \`0.2.0\`)`). Leave the table at lines 7-10 unchanged. +4. From the repo root, grep for stale version strings (the previous `.dev0` suffix, the old `SECURITY.md` parenthetical, or any other doc that still names the prior release): ```sh - git grep -n "\.dev0" + git grep -nE '\.dev0|\(currently `' ``` - Update any documentation that still names the previous dev version (for example `docs/deprecation-policy.md`). -4. Open a PR, get review, merge to `master`. -5. Tag the merge commit: + Update any hits that should name the new release (for example `docs/deprecation-policy.md`). +5. Open a PR, get review, merge to `master`. +6. Tag the merge commit: ```sh git checkout master git pull @@ -39,18 +42,28 @@ Do the changelog in one PR and the version bump in a second PR, or combine them git push origin vX.Y.Z ``` Tag format: `vMAJOR.MINOR.PATCH` (for example `v0.2.0`). -6. Publish a GitHub Release, not just the tag. Pull the `## [X.Y.Z]` section from `CHANGELOG.md` and pass it to `gh`: +7. Cut the GitHub Release after the tag. From the repo root, extract the body from `CHANGELOG.md`: ```sh - VERSION=X.Y.Z + cd "$(git rev-parse --show-toplevel)" + VERSION=0.2.0 # no leading v; not the literal X.Y.Z placeholder + VERSION="${VERSION#v}" + case "$VERSION" in + *[!0-9.]*|*.*.*.*|'') echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; + esac + NOTES="$(mktemp)" + trap 'rm -f "$NOTES"' EXIT awk -v ver="$VERSION" ' - $0 ~ "^## \\[" ver "\\]" {found=1} - found && $0 ~ "^## \\[" && $0 !~ "^## \\[" ver "\\]" {exit} - found {print} - ' CHANGELOG.md > /tmp/release-notes.md - gh release create "v${VERSION}" --title "v${VERSION}" --notes-file /tmp/release-notes.md + /^## \[/ { + if (found) exit + if ($0 ~ "^## \\[" ver "\\]") { found=1; next } + } + /^\[[^]]+\]:/ { if (found) exit } + found { print } + ' CHANGELOG.md >"$NOTES" + [ -s "$NOTES" ] || { echo "error: no CHANGELOG.md section for $VERSION" >&2; exit 1; } + gh release create "v${VERSION}" --title "v${VERSION}" --verify-tag --notes-file "$NOTES" ``` - On macOS, Linux, and Git Bash, `/tmp/release-notes.md` works. You can also create the release in the GitHub UI and paste the section there. -7. Optional: if the project later adds a supported-version table in [SECURITY.md](SECURITY.md), update it when you cut a release. `SECURITY.md` today only says fixes land on latest `master`. + On macOS, Linux, and Git Bash, `mktemp` works. Or paste the section in the GitHub UI (skip the `## [X.Y.Z]` heading; the title is already set). ## After release @@ -63,6 +76,7 @@ Do the changelog in one PR and the version bump in a second PR, or combine them |-------|----------| | Changelog format | [CHANGELOG.md](CHANGELOG.md) | | Version bump | `app.py` line 3 | +| Supported versions blurb | `SECURITY.md` line 5 | | Deprecation / semver | [docs/deprecation-policy.md](docs/deprecation-policy.md) | | Security reporting | [SECURITY.md](SECURITY.md) | | CI gates | [CONTRIBUTING.md](CONTRIBUTING.md) | From d6bc37f777e97e5462c9393895221f76eb8fbbec Mon Sep 17 00:00:00 2001 From: star-med Date: Fri, 31 Jul 2026 05:41:34 +0800 Subject: [PATCH 5/7] docs: polish RELEASING.md for review feedback and sync SECURITY to 0.2.0 --- RELEASING.md | 43 ++++++++++++++++++++++++++----------------- SECURITY.md | 2 +- 2 files changed, 27 insertions(+), 18 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index 3dc71d6..9dbc297 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -1,16 +1,16 @@ # Releasing -Manual release flow for claude-code-chat-browser. A release is an annotated git tag plus a GitHub Release with notes. No CI publish workflow, and no wheel, npm package, or other artifact. +Manual release flow for claude-code-chat-browser. A release is a git tag plus a GitHub Release with notes. No CI publish workflow, and no wheel, npm package, or other artifact. -`v0.1.0` (2026-06-18) is the only shipped tag so far. `v0.2.0` is in progress; these steps describe that cut. +`v0.1.0` (2026-06-18) and `v0.2.0` (2026-07-30) are the shipped tags so far. The steps below apply to the next cut. ## Version source The release version is `__version__` in `app.py` line 3. There is no `pyproject.toml` version field. -`SECURITY.md` line 5 names the version again in the supported-versions blurb (`(currently \`...\`)`). Keep it in sync with `app.py` on every release. `README.md` links to that page for supported versions. +`SECURITY.md` line 5 repeats that version in the supported-versions blurb. Update it whenever you bump `app.py`. `README.md` points readers at that page. -Between tagged releases, `master` may use a `.dev0` suffix (for example `0.2.0.dev0` while `0.2.0` was in development). The shipped tag drops `.dev0`. +Between tagged releases, `master` may use a `.dev0` suffix (for example `0.3.0.dev0` while the next release is in flight). The shipped tag drops `.dev0`. ## Pre-release checklist @@ -20,54 +20,63 @@ Between tagged releases, `master` may use a `.dev0` suffix (for example `0.2.0.d ## Release checklist -Do the changelog in one PR and the version bump in a second PR, or combine them on a `release/vX.Y.Z` branch. The `v0.2.0` cut used two PRs: changelog first (`docs/changelog-0-2-0`), then the bump (`release/v0.2.0`). +Do the changelog in one PR and the version bump in a second PR, or combine them on a `release/vX.Y.Z` branch. For `v0.2.0` we used two PRs: changelog first (`docs/changelog-0-2-0`), then the bump (`release/v0.2.0`). 1. Edit [CHANGELOG.md](CHANGELOG.md) ([Keep a Changelog](https://keepachangelog.com/en/1.1.0/)): - Move everything under `## [Unreleased]` into a new `## [X.Y.Z] - YYYY-MM-DD` section with `### Added`, `### Changed`, `### Deprecated`, `### Fixed`, `### Removed`, or `### Security` as needed. - Leave `## [Unreleased]` empty. - Update the footer compare links: `[Unreleased]` → `vX.Y.Z...HEAD`, add `[X.Y.Z]` → `vPREVIOUS...vX.Y.Z`. 2. On a branch from current `master`, set `app.py` line 3 to the release version without `.dev0` (for example `"0.2.0"`). -3. Update [SECURITY.md](SECURITY.md) line 5 so `(currently \`...\`)` matches that version (for example `(currently \`0.2.0\`)`). Leave the table at lines 7-10 unchanged. -4. From the repo root, grep for stale version strings (the previous `.dev0` suffix, the old `SECURITY.md` parenthetical, or any other doc that still names the prior release): +3. Update [SECURITY.md](SECURITY.md) line 5 so the "(currently ...)" parenthetical matches that version (for example `(currently 0.2.0)`). Leave the table at lines 7-10 unchanged. +4. From the repo root, grep for stale version strings (`.dev0` suffixes, the old SECURITY.md parenthetical, or the previous shipped release): ```sh - git grep -nE '\.dev0|\(currently `' + PREVIOUS=0.2.0 + PREVIOUS_ESC=$(echo "$PREVIOUS" | sed 's/[.]/\\&/g') + git grep -nE "\.dev0|\(currently \`|${PREVIOUS_ESC}" ``` - Update any hits that should name the new release (for example `docs/deprecation-policy.md`). + Point `PREVIOUS` at the release you are replacing (no `v` prefix). Fix any hits that should name the new version (for example `docs/deprecation-policy.md`). 5. Open a PR, get review, merge to `master`. -6. Tag the merge commit: +6. Tag the merge commit (lightweight tag, same as `v0.1.0` and `v0.2.0`): ```sh git checkout master git pull - git tag -a vX.Y.Z -m "vX.Y.Z" + git tag vX.Y.Z git push origin vX.Y.Z ``` Tag format: `vMAJOR.MINOR.PATCH` (for example `v0.2.0`). -7. Cut the GitHub Release after the tag. From the repo root, extract the body from `CHANGELOG.md`: +7. Publish the GitHub Release after pushing the tag. From the repo root, extract the body from `CHANGELOG.md`: ```sh cd "$(git rev-parse --show-toplevel)" VERSION=0.2.0 # no leading v; not the literal X.Y.Z placeholder VERSION="${VERSION#v}" case "$VERSION" in - *[!0-9.]*|*.*.*.*|'') echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; + *[!0-9.]*|'') echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; + *..*|.*|*.) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; + *.*.*.*) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; + *.*.*) ;; + *) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; esac NOTES="$(mktemp)" trap 'rm -f "$NOTES"' EXIT awk -v ver="$VERSION" ' + BEGIN { heading = "## [" ver "]" } /^## \[/ { if (found) exit - if ($0 ~ "^## \\[" ver "\\]") { found=1; next } + if (index($0, heading) == 1) { found=1 } } /^\[[^]]+\]:/ { if (found) exit } found { print } ' CHANGELOG.md >"$NOTES" - [ -s "$NOTES" ] || { echo "error: no CHANGELOG.md section for $VERSION" >&2; exit 1; } + grep -q '[^[:space:]]' "$NOTES" || { echo "error: no CHANGELOG.md section for $VERSION" >&2; exit 1; } gh release create "v${VERSION}" --title "v${VERSION}" --verify-tag --notes-file "$NOTES" ``` - On macOS, Linux, and Git Bash, `mktemp` works. Or paste the section in the GitHub UI (skip the `## [X.Y.Z]` heading; the title is already set). + Append a footer line after extraction, matching prior releases: + `**Full changelog:** https://github.com/cppalliance/claude-code-chat-browser/blob/vX.Y.Z/CHANGELOG.md` + On macOS, Linux, and Git Bash, `mktemp` works. Or paste the `[X.Y.Z]` section in the GitHub UI and add the same footer link. ## After release -1. On `master`, bump `app.py` `__version__` to the next development suffix if you are starting the next cycle (for example `0.3.0.dev0` after shipping `0.2.0`). Put that commit in `CHANGELOG.md` under `[Unreleased]` only when there is user-visible work; a bare dev bump can ride with the next feature PR. +1. On `master`, bump `app.py` `__version__` to the next development suffix when you start the next cycle (for example `0.3.0.dev0` after shipping `0.2.0`). Put that commit in `CHANGELOG.md` under `[Unreleased]` only when there is user-visible work; a bare dev bump can ride with the next feature PR. 2. New work goes under `## [Unreleased]` until the next release. ## References diff --git a/SECURITY.md b/SECURITY.md index ec69181..3867d75 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -2,7 +2,7 @@ ## Supported Versions -This project is pre-release. Security fixes are applied to the **latest `master` branch only** (currently `0.1.0.dev0`). +This project is pre-release. Security fixes are applied to the **latest `master` branch only** (currently `0.2.0`). | Version | Supported | | -------------- | --------- | From 7c24073d6e30261352aa87b009aac583792f13ee Mon Sep 17 00:00:00 2001 From: star-med Date: Fri, 31 Jul 2026 05:56:21 +0800 Subject: [PATCH 6/7] docs: correct SECURITY sync scope, grep pattern, and release notes footer --- RELEASING.md | 11 +++++------ docs/deprecation-policy.md | 2 +- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index 9dbc297..d3b2183 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -8,7 +8,7 @@ Manual release flow for claude-code-chat-browser. A release is a git tag plus a The release version is `__version__` in `app.py` line 3. There is no `pyproject.toml` version field. -`SECURITY.md` line 5 repeats that version in the supported-versions blurb. Update it whenever you bump `app.py`. `README.md` points readers at that page. +`SECURITY.md` line 5 names the latest shipped release in its supported-versions blurb, so update it when a tag ships, not on the `.dev0` bumps in between. `README.md` points readers at that page. Between tagged releases, `master` may use a `.dev0` suffix (for example `0.3.0.dev0` while the next release is in flight). The shipped tag drops `.dev0`. @@ -27,12 +27,12 @@ Do the changelog in one PR and the version bump in a second PR, or combine them - Leave `## [Unreleased]` empty. - Update the footer compare links: `[Unreleased]` → `vX.Y.Z...HEAD`, add `[X.Y.Z]` → `vPREVIOUS...vX.Y.Z`. 2. On a branch from current `master`, set `app.py` line 3 to the release version without `.dev0` (for example `"0.2.0"`). -3. Update [SECURITY.md](SECURITY.md) line 5 so the "(currently ...)" parenthetical matches that version (for example `(currently 0.2.0)`). Leave the table at lines 7-10 unchanged. +3. Update [SECURITY.md](SECURITY.md) line 5 so the version inside its "(currently ...)" parenthetical is the one you are shipping. Keep the surrounding formatting and leave the table at lines 7-10 unchanged. 4. From the repo root, grep for stale version strings (`.dev0` suffixes, the old SECURITY.md parenthetical, or the previous shipped release): ```sh PREVIOUS=0.2.0 PREVIOUS_ESC=$(echo "$PREVIOUS" | sed 's/[.]/\\&/g') - git grep -nE "\.dev0|\(currently \`|${PREVIOUS_ESC}" + git grep -nE "\.dev0|\(currently |${PREVIOUS_ESC}" ``` Point `PREVIOUS` at the release you are replacing (no `v` prefix). Fix any hits that should name the new version (for example `docs/deprecation-policy.md`). 5. Open a PR, get review, merge to `master`. @@ -68,11 +68,10 @@ Do the changelog in one PR and the version bump in a second PR, or combine them found { print } ' CHANGELOG.md >"$NOTES" grep -q '[^[:space:]]' "$NOTES" || { echo "error: no CHANGELOG.md section for $VERSION" >&2; exit 1; } + printf '\n**Full changelog:** https://github.com/cppalliance/claude-code-chat-browser/blob/v%s/CHANGELOG.md\n' "$VERSION" >>"$NOTES" gh release create "v${VERSION}" --title "v${VERSION}" --verify-tag --notes-file "$NOTES" ``` - Append a footer line after extraction, matching prior releases: - `**Full changelog:** https://github.com/cppalliance/claude-code-chat-browser/blob/vX.Y.Z/CHANGELOG.md` - On macOS, Linux, and Git Bash, `mktemp` works. Or paste the `[X.Y.Z]` section in the GitHub UI and add the same footer link. + The `printf` adds the same "Full changelog" footer that `v0.1.0` and `v0.2.0` carry. On macOS, Linux, and Git Bash, `mktemp` works. Or paste the `[X.Y.Z]` section in the GitHub UI and add that footer line by hand. ## After release diff --git a/docs/deprecation-policy.md b/docs/deprecation-policy.md index f8a4184..a9a4ae0 100644 --- a/docs/deprecation-policy.md +++ b/docs/deprecation-policy.md @@ -43,7 +43,7 @@ For fields **only read by the bundled SPA** (no external integrators on a tagged ## Versioning -Release versions follow `MAJOR.MINOR.PATCH` in `app.__version__` and [CHANGELOG](../CHANGELOG.md). Shipped tags include [`v0.1.0`](https://github.com/cppalliance/claude-code-chat-browser/releases/tag/v0.1.0) and [`v0.2.0`](https://github.com/cppalliance/claude-code-chat-browser/releases/tag/v0.2.0). Between releases, `main` may carry a `.dev0` suffix in `app.__version__` while developing the next version. The CHANGELOG `[Unreleased]` section is the source of truth for changes not yet tagged. +Release versions follow `MAJOR.MINOR.PATCH` in `app.__version__` and [CHANGELOG](../CHANGELOG.md). Shipped tags include [`v0.1.0`](https://github.com/cppalliance/claude-code-chat-browser/releases/tag/v0.1.0) and [`v0.2.0`](https://github.com/cppalliance/claude-code-chat-browser/releases/tag/v0.2.0). Between releases, `master` may carry a `.dev0` suffix in `app.__version__` while developing the next version. The CHANGELOG `[Unreleased]` section is the source of truth for changes not yet tagged. | Bump | Pre-1.0 meaning | |------|-----------------| From 7490e1f8e1416aabceb4d7143253a6dc37dcbe9b Mon Sep 17 00:00:00 2001 From: star-med Date: Fri, 31 Jul 2026 06:52:43 +0800 Subject: [PATCH 7/7] docs: harden RELEASING version checks and changelog extraction --- RELEASING.md | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index d3b2183..932d85a 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -49,13 +49,17 @@ Do the changelog in one PR and the version bump in a second PR, or combine them cd "$(git rev-parse --show-toplevel)" VERSION=0.2.0 # no leading v; not the literal X.Y.Z placeholder VERSION="${VERSION#v}" - case "$VERSION" in - *[!0-9.]*|'') echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; - *..*|.*|*.) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; - *.*.*.*) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; - *.*.*) ;; - *) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; - esac + case "$VERSION" in + *[!0-9.]*|'') echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; + *..*|.*|*.) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; + *.*.*.*) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; + *.*.*) ;; + *) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;; + esac + case "$VERSION" in + 0[0-9]*.*.*|*.[0][0-9]*.*|*.*.[0][0-9]*) + echo "error: VERSION components must not have leading zeros" >&2; exit 1 ;; + esac NOTES="$(mktemp)" trap 'rm -f "$NOTES"' EXIT awk -v ver="$VERSION" ' @@ -67,8 +71,8 @@ Do the changelog in one PR and the version bump in a second PR, or combine them /^\[[^]]+\]:/ { if (found) exit } found { print } ' CHANGELOG.md >"$NOTES" - grep -q '[^[:space:]]' "$NOTES" || { echo "error: no CHANGELOG.md section for $VERSION" >&2; exit 1; } - printf '\n**Full changelog:** https://github.com/cppalliance/claude-code-chat-browser/blob/v%s/CHANGELOG.md\n' "$VERSION" >>"$NOTES" + grep -v '^## \[' "$NOTES" | grep -q '[^[:space:]]' || { echo "error: no CHANGELOG.md section for $VERSION" >&2; exit 1; } + printf '\n\n**Full changelog:** https://github.com/cppalliance/claude-code-chat-browser/blob/v%s/CHANGELOG.md\n' "$VERSION" >>"$NOTES" gh release create "v${VERSION}" --title "v${VERSION}" --verify-tag --notes-file "$NOTES" ``` The `printf` adds the same "Full changelog" footer that `v0.1.0` and `v0.2.0` carry. On macOS, Linux, and Git Bash, `mktemp` works. Or paste the `[X.Y.Z]` section in the GitHub UI and add that footer line by hand. @@ -87,4 +91,4 @@ Do the changelog in one PR and the version bump in a second PR, or combine them | Supported versions blurb | `SECURITY.md` line 5 | | Deprecation / semver | [docs/deprecation-policy.md](docs/deprecation-policy.md) | | Security reporting | [SECURITY.md](SECURITY.md) | -| CI gates | [CONTRIBUTING.md](CONTRIBUTING.md) | +| CI gates | [`.github/workflows/ci.yml`](.github/workflows/ci.yml), [CONTRIBUTING.md](CONTRIBUTING.md) |