chore(release): update changelog and bump version to 4.0.0

[shumkov]

Issue being fixed or feature implemented

Release new Dash Platform version

What was done?

• Updated changelog
• Bumped packages version

How Has This Been Tested?

None

Breaking Changes

None

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

Summary by CodeRabbit

• Chores
  • Updated workspace and package versions from release-candidate builds to final stable releases (including main packages and select packages at 5.0.0/7.0.0/11.0.0).
• Bug Fixes
  • Improved the config upgrade process to refresh platform Docker image tags during migration to version 4.0.0.
• Tests
  • Added a unit test covering the updated config migration behavior for stale Docker image tags.
• Documentation
  • Updated the changelog with the new v4.0.0 release entry.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0e011f39-7ff1-4dbb-8e6a-93e81d77d845

📥 Commits

Reviewing files that changed from the base of the PR and between 7d863ae and 217a1e6.

📒 Files selected for processing (3)

• CHANGELOG.md
• packages/dashmate/configs/getConfigFileMigrationsFactory.js
• packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js

💤 Files with no reviewable changes (1)

• CHANGELOG.md

---

📝 Walkthrough

Walkthrough

This PR finalizes the release version across workspace and package manifests, adds the v4.0.0 changelog entry, and introduces a dashmate config migration that repins Drive ABCI and rs-dapi docker images with test coverage.

Changes

Release v4.0.0 update

Layer / File(s)	Summary
Workspace manifests version bump Cargo.toml, package.json	Root workspace package versions move from 4.0.0-rc.2 to 4.0.0.
Sub-package manifests version bump packages/bench-suite/package.json, packages/dapi-grpc/package.json, packages/dapi/package.json, packages/dash-spv/package.json, packages/dashmate/package.json, packages/dashpay-contract/package.json, packages/dpns-contract/package.json, packages/js-dapi-client/package.json, packages/js-dash-sdk/package.json, packages/js-evo-sdk/package.json, packages/js-grpc-common/package.json, packages/keyword-search-contract/package.json, packages/masternode-reward-shares-contract/package.json, packages/platform-test-suite/package.json, packages/token-history-contract/package.json, packages/wallet-lib/package.json, packages/wallet-utils-contract/package.json, packages/wasm-dpp/package.json, packages/wasm-dpp2/package.json, packages/wasm-drive-verify/package.json, packages/wasm-sdk/package.json, packages/withdrawals-contract/package.json	Package versions move from release-candidate identifiers to final release versions, including 7.0.0-rc.2 to 7.0.0, 5.0.0-rc.2 to 5.0.0, and 11.0.0-rc.2 to 11.0.0.
v4.0.0 changelog entry CHANGELOG.md	The changelog adds the v4.0.0 header plus sections for breaking changes, features, bug fixes, CI, documentation, tests, refactoring, build system updates, and chores.
Dashmate config migration packages/dashmate/configs/getConfigFileMigrationsFactory.js, packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js	A 4.0.0 migration repins Drive ABCI and rs-dapi docker image tags from base config values, and the unit test verifies the migrated image values.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related issues

• dashmate update keeps old drive/rs-dapi image on 3.0.x -> 4.0.0-rc.x upgrade (node stays on protocol 11, crash-loops after protocol 12 activation) #3889: Adds the missing 4.0.0 dashmate config migration that re-syncs Drive ABCI and rs-DAPI images.

Possibly related PRs

• dashpay/platform#3708: Both PRs update workspace/package version metadata and changelog content for a release.
• dashpay/platform#3846: Both PRs are release/version bumps touching the same manifest version fields.
• dashpay/platform#2606: Both PRs update version strings across overlapping package manifests.

Suggested reviewers: QuantumExplorer, thepastaclaw

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the release changelog update and version bump to 4.0.0.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch release_4.0.0

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

✅ Review complete (commit 217a1e6)

[thepastaclaw]

Code Review

Release finalization for Platform 4.0.0 is largely clean — workspace Cargo.toml/lock and all internal Rust crates consistently move rc.2 → 4.0.0, the changelog matches the git range, and the docs branch retargeting from v3.1-dev to v4.0-dev is coherent. However, three published npm packages (dash, @dashevo/wallet-lib, @dashevo/dash-spv) that were on independent major lines (7.x, 11.x, 5.x) are being downgraded to 4.0.0, which is a semver regression against their previously published rc.2 series.

🔴 3 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/js-dash-sdk/package.json`:
- [BLOCKING] packages/js-dash-sdk/package.json:3: `dash` npm package is being downgraded from 7.0.0-rc.2 to 4.0.0
  The public npm package `dash` (this workspace) was set to `7.0.0-rc.2` in the prior release bump (#3864, commit 1ba1ca5828) and had been tracking an independent 7.x major line separate from the Platform version. This PR finalizes it to `4.0.0`, which is a semver regression: consumers pinned to `^7.0.0-rc` cannot resolve to the final release, and the npm registry history for `dash` will show a downgrade. Finalizing the 7.0.0-rc.2 line should publish 7.0.0.

In `packages/wallet-lib/package.json`:
- [BLOCKING] packages/wallet-lib/package.json:3: `@dashevo/wallet-lib` is being downgraded from 11.0.0-rc.2 to 4.0.0
  The prior release (commit 1ba1ca5828) set `@dashevo/wallet-lib` to `11.0.0-rc.2`, continuing its independent 11.x major line. This PR finalizes it to `4.0.0`, which is a semver downgrade of a published npm package. Consumers pinned to the 11.0.0 rc range will not resolve to this release, and the package's semver history will regress. The natural finalization of `11.0.0-rc.2` is `11.0.0`.

In `packages/dash-spv/package.json`:
- [BLOCKING] packages/dash-spv/package.json:3: `@dashevo/dash-spv` is being downgraded from 5.0.0-rc.2 to 4.0.0
  `@dashevo/dash-spv` was on `5.0.0-rc.2` before this PR (commit 1ba1ca5828), on its own 5.x major line. This PR sets it to `4.0.0`, which is a semver downgrade. Finalizing the 5.0.0-rc.2 prerelease should publish `5.0.0`; otherwise the npm registry release will not satisfy any consumer pinned to the 5.x rc line and will appear as a regression.

[thepastaclaw]

Code Review

Latest push (7d863ae) resolves all three prior blocking version-downgrade findings by restoring the required major-version offsets: dash-spv=5.0.0 (root+1), dash=7.0.0 (root+3), wallet-lib=11.0.0 (root+7). However, the 830fbd9 release commit that populated CHANGELOG.md added 1351 lines that duplicate the entire prior release history — 4.0.0-rc.2/rc.1/beta.4/beta.3/beta.2/beta.1 now appear twice in the file (once at lines 121-253, again starting at line 1352). For a release-preparation PR whose stated purpose is changelog correctness, this remains blocking.

🔴 1 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `CHANGELOG.md`:
- [BLOCKING] CHANGELOG.md:121-253: Release history duplicated in CHANGELOG
  The 4.0.0 release commit prepended 1351 lines that include not only the new 4.0.0 section but also fresh copies of 4.0.0-rc.2, 4.0.0-rc.1, 4.0.0-beta.4, 4.0.0-beta.3, 4.0.0-beta.2, and 4.0.0-beta.1. The previous versions of those same sections still exist further down (starting at line 1352), so every pre-release section from 4.0.0-rc.2 through 4.0.0-beta.1 is now present twice. Since this PR's whole purpose is producing a correct 4.0.0 changelog, only the new 4.0.0 section (lines 1-119) should be added; the duplicated tail (lines 121-1351 of the additions) needs to be dropped so the file resumes cleanly with the pre-existing 4.0.0-rc.2 block. Re-running the changelog generator against the correct base (post-4.0.0-rc.2 tag) rather than an empty base should produce the intended diff.

[thepastaclaw]

Code Review

Prior blocking CHANGELOG duplication finding is FIXED — the current head cleanly removes the duplicated pre-release sections. New delta review carries forward one release-metadata consistency suggestion: the standalone qa-contract package still declares the SDK dependency as ^4.0.0-rc.2 while this release bumps the SDK to 4.0.0 final. No blockers remain.

🟡 2 suggestion(s)

Findings not posted inline (1)

These findings could not be anchored to the current diff, but they are still part of this review.

• [SUGGESTION] qa-contract/package.json:19: Stale rc.2 SDK range in standalone qa-contract package — This PR bumps packages/js-evo-sdk/package.json and the rest of the workspace from 4.0.0-rc.2 to the final 4.0.0, but the standalone qa-contract package still declares @dashevo/evo-sdk at ^4.0.0-rc.2. Its README documents standalone npm install as the intended path (qa-contract is in...

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `qa-contract/package.json`:
- [SUGGESTION] qa-contract/package.json:19: Stale rc.2 SDK range in standalone qa-contract package
  This PR bumps `packages/js-evo-sdk/package.json` and the rest of the workspace from `4.0.0-rc.2` to the final `4.0.0`, but the standalone `qa-contract` package still declares `@dashevo/evo-sdk` at `^4.0.0-rc.2`. Its README documents standalone `npm install` as the intended path (qa-contract is intentionally not a Yarn workspace member), so the range publicly advertises the RC version for this in-repo consumer at the 4.0.0 tag. The caret range does accept 4.0.0 semver-wise, so this is not a functional break — but a release/version-bump PR is the right moment to normalize the range so no consumer install log references the RC.
- [SUGGESTION] qa-contract/package.json:19: Stale rc.2 SDK range in standalone qa-contract package
  This PR bumps `packages/js-evo-sdk/package.json` and the rest of the workspace from `4.0.0-rc.2` to the final `4.0.0`, but the standalone `qa-contract` package still declares `@dashevo/evo-sdk` at `^4.0.0-rc.2`. Its README documents standalone `npm install` as the intended path (qa-contract is intentionally not a Yarn workspace member), so the range publicly advertises the RC version for this in-repo consumer at the 4.0.0 tag. The caret range does accept 4.0.0 semver-wise, so this is not a functional break — but a release/version-bump PR is the right moment to normalize the range so no consumer install log references the RC.

[thepastaclaw]

Code Review

Carried-forward prior finding: qa-contract/package.json still declares @dashevo/evo-sdk at ^4.0.0-rc.2 while packages/js-evo-sdk is now at final 4.0.0 — verified against SHA 217a1e6. No new findings in the latest delta (drive/rs-dapi image re-pin migration mirrors the neighboring tenderdash pattern and includes a unit test).

🟡 2 suggestion(s)

Findings not posted inline (1)

These findings could not be anchored to the current diff, but they are still part of this review.

• [SUGGESTION] qa-contract/package.json:19: Stale rc.2 SDK range in standalone qa-contract package — This release PR bumps packages/js-evo-sdk/package.json to the final 4.0.0 (verified at line 3), but the standalone qa-contract package still declares @dashevo/evo-sdk at ^4.0.0-rc.2. Since qa-contract is intentionally kept outside the Yarn workspace and installed directly via `npm ins...

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `qa-contract/package.json`:
- [SUGGESTION] qa-contract/package.json:19: Stale rc.2 SDK range in standalone qa-contract package
  This release PR bumps `packages/js-evo-sdk/package.json` to the final `4.0.0` (verified at line 3), but the standalone `qa-contract` package still declares `@dashevo/evo-sdk` at `^4.0.0-rc.2`. Since `qa-contract` is intentionally kept outside the Yarn workspace and installed directly via `npm install`, the 4.0.0 release tag publicly advertises an RC-based SDK dependency for this in-repo consumer. The caret range does resolve to 4.0.0, so this is not a functional break — but a release/version-bump PR is the right moment to normalize the range so no install log or lockfile references the RC prerelease.
- [SUGGESTION] qa-contract/package.json:19: Stale rc.2 SDK range in standalone qa-contract package
  This release PR bumps `packages/js-evo-sdk/package.json` to the final `4.0.0` (verified at line 3), but the standalone `qa-contract` package still declares `@dashevo/evo-sdk` at `^4.0.0-rc.2`. Since `qa-contract` is intentionally kept outside the Yarn workspace and installed directly via `npm install`, the 4.0.0 release tag publicly advertises an RC-based SDK dependency for this in-repo consumer. The caret range does resolve to 4.0.0, so this is not a functional break — but a release/version-bump PR is the right moment to normalize the range so no install log or lockfile references the RC prerelease.