Downshift has one published release channel:
- Stable releases: GitHub Release + npm publish
Development builds are tested locally with pi -e ., pi install ., or a local packed tarball.
Use Conventional Commits:
fix: prevent duplicate handoff prompts
feat: add steered continuation after handoff
docs: clarify prompt caching behavior
chore: update release workflow
Release Please uses these commits to generate changelog entries and version bumps.
Release Please owns release version files:
package.jsonpackage-lock.jsonCHANGELOG.md.release-please-manifest.json
Do not manually bump package.json for a release.
To request an exact version, create a Release-As: commit:
git commit --allow-empty \
-m "chore: release 0.2.1" \
-m "Release-As: 0.2.1"
git push origin mainIf the repo has the helper script, use:
npm run release:as -- 0.2.1Then run the release-please workflow manually.
Stable releases are controlled through Release Please.
- Merge normal feature/fix PRs into
main. - Optional: create a
Release-As:commit if the release must use an exact version. - Go to GitHub Actions.
- Run the
release-pleaseworkflow manually. - Review the Release Please PR.
- Merge the Release Please PR when ready.
- The merge changes
package.json,package-lock.json,CHANGELOG.md, and.release-please-manifest.json. - That release-file push runs
release-pleaseagain automatically. - Release Please creates the GitHub Release and tag.
- The
publish-npmjob waits for thenpm-publishenvironment approval. - Approve the deployment.
- The package publishes to npm.
Verify:
npm view pi-downshift version
pi install npm:pi-downshiftStable releases must use tags like:
v0.2.0
v1.0.0
Run:
npm run release:dryThis runs typecheck, tests, and npm pack --dry-run.
Test locally without publishing:
pi -e .Or install from the local package path:
pi install .Or test the packed package:
npm pack
pi install ./pi-downshift-<version>.tgz