Repository navigation
chore(release): prepare v1.4.1 - #2245
Conversation
| 'Reduce repeated database work by consolidating context recall queries, batching Memory lifecycle and authorization checks, reusing exact evidence revisions, and batching cited Experience reads. Scheduled processing skips consumed Scope windows, and Source capture can proceed while Memory extraction is running.', | ||
| 'Remove duplicate Source text from Atomic Memory extraction requests and compact repeated bodies in additional model projections. Skip reconciliation when a candidate has no comparable memories, and return invalid reconciliation decisions to the model for correction within the configured retry budget.', | ||
| 'Export, inspect, validate, and restore selected complete Scopes as portable .pcb archives. Preserve exact identities, revisions, evidence, and supported review state; validate conflicts before writes and recognize identical records on replay. This is an offline operator workflow, excludes deployment credentials and derived indexes, and does not replace a complete database backup or schema migration.', | ||
| 'Complete the Server migration framework with registered source recognition, schema and data transitions, resumable recovery, and full Server readiness checks. Upgrade support requires acceptance against the exact release artifact; the twelve-case release gate covers 1.3.0 across SQLite, seekDB, and OceanBase, while the 1.4.0 bridge is outside that gate.', |
There was a problem hiding this comment.
Previous finding: addressed in substance. The rewrite now describes the framework as #2168's work and states the acceptance boundary (twelve 1.3.0 cases across the three backends; 1.4.0 bridge outside the gate), and the install guide now forbids in-place upgrades instead of implying support. That resolves the v1.4.0-capability-attributed-to-1.4.1 problem from r4374916520 (now resolved).
Remaining: this commit ships #2168's artifacts without #2168. Verified in this branch:
docs/{en,zh}/docs/get-started/install-and-run.mdat025646d9are byte-identical to the same paths in feat(migrations): complete the reusable database upgrade framework #2168 (be7f2f89…and255791b5…). The notice text is literallyscripts/upgrade_release_gate.py::NOTICEthere (l.62-64), and the<!-- upgrade-support:start/end -->region is only parsed there (l.195-197, "exactly one upgrade-support region required").- Neither
scripts/upgrade_release_gate.py,scripts/run_upgrade_release_gate.py,release/upgrade-support.json,tests/release_upgrades/, nor.github/workflows/upgrade-release.ymlexists in this branch. So the marker is inert here, andinstall-and-run.md:185("checked against the release matrix and installed-artifact acceptance; see Preparing a release") points at adocs/en/development/releasing.mdsection — Database upgrade support — that only feat(migrations): complete the reusable database upgrade framework #2168 adds; releasing.md in this branch (166 lines) has no upgrade or matrix text at all. install-and-run.md:193requiresstate=readyandserver_ready=true, which this branch cannot produce:docs/*/docs/operate/database-migrations.md:23,45(unchanged) still reportreadiness_scope=registered_bundleandserver_ready=false.
Consequence: the branch is only shippable after #2168 — "Depends on #2168" in the description needs to be a hard precondition, not a preference.
Two files will collide with #2168, and for one of them a clean textual merge is not enough:
tests/test_release_version.py— same four-line deletion, different replacement: here"Upgrades from 1.3.0 and 1.4.0 require"/"1.3.0 和 1.4.0 升级必须"; in feat(migrations): complete the reusable database upgrade framework #2168"…require passing full Server acceptance"/"…升级必须通过 SQLite、seekDB 和 OceanBase 的完整 Server 验收". Keeping the shorter variant silently weakens the notice assertion.website/src/lib/releases.ts— both add av1.4.1entry, andwebsite/tests/releases.test.ts:38asserts exactly one entry per version. If both entries survive the rebase, the website test fails on master. feat(migrations): complete the reusable database upgrade framework #2168's entry also carries content this one omits:db-migrate status/plan/apply/verify, thev1_4_1_001..003step IDs, and the 1.3.0 Dream queued/running drain step.
Suggested integration: after #2168 lands, drop the scripts/release_version.py, tests/test_release_version.py, and both install-page hunks from this PR — they become no-ops (byte-identical or strictly weaker) — and keep a single v1.4.1 entry that folds in #2168's five bullets. Then re-run make release-check VERSION=1.4.1.
Re-verified on 025646d9, unchanged from 80047b99: release_version.py --check reports "Release references match 1.4.1" with planned_updates empty; 69 tests pass (test_release_version, test_api_contract, test_desktop_contract, test_desktop_fixture_qualification); the contract digest recomputes to c12901b8… and openapi/powercontext.yaml, operations.json, compatibility.json are byte-identical, so the Desktop qualification record still applies; all ten 1.4.1 occurrences in each install page sit on a managed prefix, so the new ^To install / ^安装 patterns leave no unmanaged pin behind.
| // Only stable releases belong here; publish pre-release notes on GitHub Releases. | ||
| export const releases: Release[] = [ | ||
| { | ||
| version: 'v1.4.1', |
There was a problem hiding this comment.
Status change since my last pass: the branch is unchanged at 025646d9, but master moved to e273457d (feat(migrations): complete the reusable database upgrade framework (#2168), 17:16 +08). The PR is now CONFLICTING / merge_state_status=DIRTY. This is the precondition I described in r4375168200, not a new defect — but the rebase has one right answer per file, and two of them are traps.
#2168 already landed the entire version preparation. On e273457d, openapi/powercontext.yaml is 1.4.1, and the three READMEs, both install-and-run.md pages, both manual-start.md and quickstart.md pages, the Dify contract, desktop/src-tauri/src/transport/operations.json, desktop/ui/src/generated/operations.ts and both _generated Python files are byte-identical to this branch. 16 of the 24 files in this PR are now no-ops; 8 still differ:
| File | Resolution |
|---|---|
scripts/release_version.py |
Merges cleanly. Keep master's copy — it additionally registers release/upgrade-support.json (line 36). Do not resolve by pasting the PR side, that unregisters the new managed target. |
tests/test_release_version.py |
Take master's side. The PR side drops release/upgrade-support.json from the fixture file list and shortens the notice assertions to "Upgrades from 1.3.0 and 1.4.0 require" / "1.3.0 和 1.4.0 升级必须"; master asserts the full sentence including SQLite、seekDB 和 OceanBase. Taking this side silently removes coverage of the new managed file and weakens the notice assertion. |
tests/test_api_contract.py |
Base is == "1.4.0", master re-hardcodes == "1.4.1", this PR uses == API_VERSION. Keep this PR's version — it is the one change here that still improves the tree — and confirm api-generate-check remains the drift guard. |
website/src/lib/releases.ts |
Keep one v1.4.1 entry. website/tests/releases.test.ts:38 asserts exactly one entry per version, and master's entry already carries five bullets including db-migrate status/plan/apply/verify, v1_4_1_001..003 and the 1.3.0 Dream drain step. Dropping this PR's entry (lines 31-74) is the safe resolution. |
desktop/README.md, desktop/README.zh.md, desktop/VALIDATION.md, desktop/.../compatibility.json |
Both sides qualify the same contract digest c12901b8…. Master ships sqlite-atomic-dd62723d-v1 (commit dd62723d, wheel …dev293+gdd62723dc, SHA-256 030c6a46…, 609 packaged files); this PR ships sqlite-atomic-4ffdf4e9-v1 (commit 4ffdf4e9, wheel …dev176+g4ffdf4e97, SHA-256 33079ebc…, 552 packaged files). A duplicate digest is not a runtime violation — master already carries 5878999c… twice (sqlite-atomic-1da99747-v1 and sqlite-atomic-8f10c560-v1) — but the prose is not mergeable as-is: both READMEs and VALIDATION.md would then state "the current contract is qualified by " twice. Pick one record; if you keep 4ffdf4e9, note that master's sentence enumerates sqlite-atomic-8f10c560-v1 among the non-matching records and this side does not. |
Suggestion: #2168 landed the whole release preparation, so this PR's unique residual is the 4ffdf4e9 Desktop qualification plus the API_VERSION assertion. Either rebase to exactly those two changes, or drop the qualification as well — the tag will be cut from the merge commit, so a wheel built from 4ffdf4e9 is no closer to the published artifact than master's dd62723d wheel.
Verified on e273457d: scripts/release_version.py --check reports "Release references match 1.4.1", and test_release_version, test_api_contract, test_desktop_contract, test_desktop_fixture_qualification pass (69 tests). So master is self-consistent and the release is not blocked by the conflict itself.
Re-run after the rebase: make version-check, make contract-test, make release-check VERSION=1.4.1, pnpm --dir desktop generate:check, pytest tests/test_desktop_fixture_qualification.py.
One thread instead of six: all eight files share the single cause (the #2168 merge), so the desktop conflicts are listed by path above rather than duplicated as separate comments.
Which issue or RFC does this PR close?
Prepares the PowerContext v1.4.1 release and incorporates the database upgrade framework merged in #2168.
Rationale for this change
The v1.4.1 website entry needs to cover the release's performance, archive, Agent, Desktop, and database upgrade changes together. Keep one bilingual entry and describe upgrade acceptance consistently with the implemented publication policy.
What changes are included in this PR?
4ffdf4e9Desktop qualification alongside thedd62723drecord from feat(migrations): complete the reusable database upgrade framework #2168, retaining each source, contract, wheel, and evidence identity. The Desktop guidance uses the upstream migration-framework qualification.API_VERSIONinstead of hardcoding a release number in the contract test.The version tooling, installation guides, generated API metadata, and stricter release-version assertions use the merged #2168 implementation. The release branch includes
origin/mainate273457d; there is no outstanding implementation dependency on #2168.Are there any user-facing changes?
The website has one combined v1.4.1 release entry and explicit upgrade support boundaries. Existing databases require an accepted source/backend path for the exact target artifact before upgrading. Historical Desktop qualification records remain tied to their tested source and wheel.
This PR does not publish a package, create a release tag, or deploy the website. Python distribution versions continue to come from Hatch VCS.
How was this change tested?
make release-check VERSION=1.4.1— version references, generated contracts, upgrade policy, installation notices, and the bilingual release entry passed.uv run pytest tests/test_release_version.py tests/test_api_contract.py tests/test_desktop_contract.py tests/test_desktop_fixture_qualification.py tests/test_upgrade_release_gate.py tests/test_upgrade_publication.py -q— 178 passed.make docs-test— 30 website tests, link validation, and static export passed (977 public pages). The final release-guide prose was then regenerated and exported again.git diff --checkand formatting/lint hooks passed.Known baseline failure: full
uv run prek run -afails only attybecausetests/e2e/cross_host_work_continuity/fixtures/verify.py:23cannot resolvetask. This unchanged fixture produced the same diagnostic before the merge.The upgrade gate tests verify orchestration and failure handling; they do not establish installed-release database upgrade acceptance. Native session tests do not establish packaged GUI or platform qualification. The retained qualification records describe the original tested commits and artifacts.
AI usage statement
Prepared with OpenAI Codex (GPT-6), including conflict resolution, release-note integration, version and upgrade-policy verification, and validation. Diffs and test results were inspected before submission.