From dcb04a4802420b41bf88ca25f1265e5cd253e74d Mon Sep 17 00:00:00 2001 From: Mohamed Boudra Date: Tue, 28 Apr 2026 20:07:25 +0700 Subject: [PATCH] docs: 0.1.64 changelog and rollout docs Add 0.1.64 release notes and document the instant-admit release path (release:patch + immediate desktop-rollout.yml dispatch) so future fast-rollout releases follow a single canonical flow. --- CHANGELOG.md | 15 +++++++++++++++ docs/RELEASE.md | 30 ++++++++++++++++++++++++++---- 2 files changed, 41 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2134a70ba..174a36277 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,20 @@ # Changelog +## 0.1.64 - 2026-04-28 + +### Added + +- OpenCode now has a Full Access mode that auto-approves tool calls. ([#595](https://github.com/getpaseo/paseo/pull/595) by [@tmih06](https://github.com/tmih06)) +- OpenCode supports executable slash commands. ([#597](https://github.com/getpaseo/paseo/pull/597) by [@tmih06](https://github.com/tmih06)) + +### Improved + +- `@`-mention stays responsive on very large projects. ([#600](https://github.com/getpaseo/paseo/pull/600) by [@yuruiz](https://github.com/yuruiz)) + +### Fixed + +- Workspaces still load when `paseo.json` has a parse error. + ## 0.1.63 - 2026-04-28 ### Added diff --git a/docs/RELEASE.md b/docs/RELEASE.md index 67c275cfc..ce5af344b 100644 --- a/docs/RELEASE.md +++ b/docs/RELEASE.md @@ -69,11 +69,31 @@ The rollout is driven by a `rolloutHours` field stamped into the GitHub Release `npm run release:patch` → tag push → 24h ramp. No extra action needed. +The `rollout_hours` input on `desktop-release.yml` is **only read on `workflow_dispatch`** — tag-push runs always default to 24. To get any other rollout duration on a fresh release, use the post-publish flip below. + +### Instant-admit release (rollout_hours=0 from publish) + +For a fresh release that should admit everyone immediately (low-risk change, doc-only, hotfix, or just a release you want out fast), cut the release normally and queue the rollout flip immediately after: + +```bash +# 1. Cut and publish (default 24h ramp from tag push). +npm run release:patch + +# 2. Immediately queue the flip — runs as soon as finalize-rollout completes. +gh workflow run desktop-rollout.yml \ + -f tag=v0.1.64 \ + -f rollout_hours=0 +``` + +**Why this is gap-free:** `desktop-release.yml`'s `finalize-rollout` job and `desktop-rollout.yml` share the concurrency group `desktop-rollout-`. Dispatching `desktop-rollout.yml` while the tag-push pipeline is still running queues it safely behind `finalize-rollout`. The release manifest goes from `rolloutHours=24` to `rolloutHours=0` within ~30s of publish, and the renderer polls every 30 minutes — so no stable user can admit during the gap. + +Run the dispatch right after `release:patch` returns. Don't wait for the tag-push CI to finish. + ### Adjusting an already-published release To change the rollout duration on a release that's already shipped — e.g. flip a hotfix to instant admit, or slow a release down — use the dedicated `desktop-rollout.yml` workflow. It edits the manifests in place on the GitHub release without rebuilding anything. It only rewrites `rolloutHours`; `releaseDate` is preserved, so the rollout clock keeps ticking from the original publish time. -**Hotfix (instant admit):** +**Hotfix (instant admit) on an already-shipped release:** ```bash gh workflow run desktop-rollout.yml \ @@ -93,11 +113,11 @@ gh workflow run desktop-rollout.yml \ `rollout_hours` is **total duration since the original release date**, not "extend by N more hours from now." If `v0.1.42` was published 2h ago and you set `rollout_hours=72`, the ramp finishes 70h from now. -The dispatch is idempotent and shares a concurrency group with `desktop-release.yml`'s `finalize-rollout` job keyed on the tag, so it serializes safely against an in-flight tag-push pipeline targeting the same release. +The dispatch is idempotent and shares the `desktop-rollout-` concurrency group with `desktop-release.yml`'s `finalize-rollout` job, so it serializes safely against an in-flight tag-push pipeline targeting the same release. -### Faster ramp at release time +### Custom ramp on a manually-dispatched build -For low-risk changes (doc-only, dependency bumps with no behavior change), trigger `desktop-release.yml` manually with a shorter rollout window so the build itself stamps a smaller `rolloutHours`: +`desktop-release.yml` accepts `rollout_hours` only on `workflow_dispatch`, which is the path used to **rebuild an existing tag** (retry a failed release, force a rebuild on a different ref). When you go that route, you can stamp a non-default ramp directly: ```bash gh workflow run desktop-release.yml \ @@ -105,6 +125,8 @@ gh workflow run desktop-release.yml \ -f rollout_hours=6 ``` +This does **not** apply to fresh releases cut via `npm run release:patch` — that path always tag-pushes and stamps 24. For a fresh release with a custom ramp, cut normally and then dispatch `desktop-rollout.yml` (same pattern as the instant-admit flow above, with your chosen `rollout_hours`). + ### Releasing during an active rollout If you ship N+1 while N is still ramping, N+1 starts a fresh rollout from its own publish timestamp. N's rollout effectively ends — the newer manifest supersedes it.