Skip to content

chore: bump version to 0.8.2 - #146

Merged
zhengchaol merged 1 commit into
mainfrom
release/v0.8.2
Aug 11, 2026
Merged

chore: bump version to 0.8.2#146
zhengchaol merged 1 commit into
mainfrom
release/v0.8.2

Conversation

@zhengchaol

Copy link
Copy Markdown
Contributor

Release 0.8.2

Bumps version from 0.8.1 to 0.8.2.

When this PR is merged to main, the release workflow will automatically:

  • Create tag v0.8.2
  • Create a GitHub Release with auto-generated notes
  • Build binaries for all platforms
  • Publish to PyPI
  • Publish to npm

@zhengchaol
zhengchaol merged commit 29bf9b9 into main Aug 11, 2026
7 checks passed
@zhengchaol
zhengchaol deleted the release/v0.8.2 branch August 11, 2026 01:04
zhengchaol added a commit that referenced this pull request Aug 14, 2026
* chore: sync uv.lock with the 0.8.2 version bump

The 0.8.2 bump (#146) updated pyproject.toml, __init__.py, the cloud
function requirements, and npm/package.json, but left uv.lock pinning
the editable parallel-web-tools entry at 0.8.1 — the same slip the
0.8.1 release made (fixed by hand in #145). Any uv sync regenerates the
entry, so the lock has been showing as dirty in working trees since the
release.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: keep uv.lock in sync with release version bumps

Every release bump has left uv.lock stale on main: release.sh rewrites
pyproject.toml but never re-locks, so the lock's own-package entry keeps
the previous version and the first uv sync in any working tree dirties
it. It happened at 0.8.1, was hand-patched in #145, and happened again
at 0.8.2.

Run uv lock as part of update_version_files and stage uv.lock in the
release commit. Add a `uv lock --check` step to the CI lint job so a
stale lock fails the release PR instead of surfacing later — `uv sync`
alone silently re-locks in the runner and can never catch it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: mirror project skill installs into .claude when Claude Code exists

`skills install --project` only wrote `<root>/.claude/skills` when
`<root>/.claude` already existed. A repo that has never stored Claude
settings has no `.claude` directory, so on exactly the machines that do
run Claude Code, project installs landed only in `.agents/skills` — a
location Claude Code never reads — and the skills were silently
invisible.

A missing `<root>/.claude` doesn't mean the user isn't running Claude
Code there; a missing machine-level configuration directory does.
Project installs now create `<root>/.claude/skills` whenever the
machine-level Claude config dir (CLAUDE_CONFIG_DIR or ~/.claude)
exists. The mirror stays project-local — the global config dir is only
consulted as the Claude-Code-is-present signal, never as a target.
Global installs are unchanged.

Also refresh the --project help strings, which still described the
pre-#145 single-directory behavior.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant