chore: bump version 2.5.0

[piotr-iohk]

Release 2.5.0.

Description

• Bump versionCode to 189 and versionName to 2.5.0
• Collect changelog fragments from changelog.d/next/ into CHANGELOG.md under [2.5.0] - 2026-09-10

Design

N/A — no UI changes.

Preview

N/A

QA Notes

N/A — version bump and changelog only.

[greptile-apps]

Confidence Score: 4/5

The release metadata appears safe to merge after addressing the non-blocking changelog whitespace inconsistency.

Findings

1.  Excess changelog whitespace ▶

Summary

• Bumps the application version from 2.4.1/188 to 2.5.0/189.
• Collects 36 changelog fragments into the dated 2.5.0 release section and updates comparison links.
• Removes the collected fragments from changelog.d/next/.
• Leaves a minor excess-whitespace issue in the changelog.

_{Reviews (1) · Last reviewed commit: "chore: version 2.5.0"}

[jvsena42]

Release mechanics check out. No findings — safe to ship from my side.

Version: app/build.gradle.kts:189-190 → versionCode = 189, versionName = "2.5.0". Previous release (git cat-file -p "v2.4.1^{commit}:app/build.gradle.kts") was 188 / 2.4.1, so monotonic +1. I also checked the ABI-split logic, since the APK/AAB output code was restructured between 2.4.1 and 2.5.0 (applicationVariants.all → androidComponents.onVariants) — neither form applies an ABI offset to versionCode, both only rename output files, so the Play-uploaded AAB goes 188 → 189 with no regression.

Changelog consumption — all 36 fragments verified individually, not spot-checked:

• 36 fragments deleted (the 37th path is .gitkeep, correctly retained), 36 bullets in the new section. 1:1.
• Each fragment's exact text appears exactly once, under a heading matching its filename category. Zero dropped, zero duplicated, zero miscategorised. Category counts match filenames: added 11, changed 3, fixed 19, security 3.
• Issue-ID sets identical between fragment filenames and the #NNNN suffixes (sorted diff is empty).
• Released sections untouched — everything from ## [2.4.1] down is byte-identical apart from the link-reference block, which correctly repoints [Unreleased] and adds the [2.5.0] compare link. That's the expected mechanical output, not a manual edit.
• No changelog.d/hotfix/ fragments swept in (that dir holds only .gitkeep at both base and head).

Stray changes: none. git diff --name-status is exactly M CHANGELOG.md, M app/build.gradle.kts, and 36 D changelog.d/next/*.md.

Semver: 2.5.0 is right. Even discounting the Paykit and dev-only entries, Trezor on-chain send (#1187), the Trezor Receive tab (#1189), hidden/passphrase Trezor wallets (#1142) and HW-name backup (#1173) are reachable new features, so a minor is justified rather than a patch.

---

One thing worth knowing before you publish, not a change request.

2.5.0 ships Paykit as reachable opt-in code, not dead-but-linked code. I traced it because I'd been assuming the opposite:

• PAYKIT_UI_DISABLED (app/build.gradle.kts:84, default false) is set nowhere — not in any workflow, not in the justfile — so PaykitFeatureFlags.isUiAvailable is true in a mainnet release build.
• The user flag does default false (SettingsStore.kt:42) ✅, and isDevModeEnabled defaults to Env.isDebug (:138).
• But the 5-tap version-row handler (SupportScreen.kt:104-110) has no build-type guard — no BuildConfig.DEBUG, no Env.isDebug — so in a stock Play Store build: Settings → About → tap version 5× → Advanced → Dev Settings → Enable Paykit UI → confirm, and the whole Paykit surface lights up.

Relatedly, every release tag already carries the dependency (v2.3.2 rc8, v2.4.0 rc31, v2.4.1 rc31, v2.5.0 rc51). Use git cat-file -p "<tag>^{commit}:<path>" to check — git show <tag>:<path> gives false negatives against these annotated tags, which is how I got it wrong the first time.

12 of the 36 bullets describe Paykit capability in plain "Bitkit can now…" voice with no gating qualifier. I considered filing that and decided against it, for three reasons: several of those bullets are Fixed entries on Paykit internals (#1131, #1108, #1141) where a "while enabled in Dev Settings" suffix would be noise rather than accuracy; there's no fastlane or store-metadata pipeline in this repo, so the blast radius is the GitHub release body read by technical users; and the fragments were authored verbatim upstream in already-merged PRs, so this PR only consumed them mechanically.

If you want it addressed, the cheap fix is one sentence in the GitHub draft release description — "Paykit / subscription features are staged behind Dev Settings and off by default" — covering all 12 bullets with zero code and no edits to merged fragments.

Please don't fix it by setting PAYKIT_UI_DISABLED=true for the release. On the iOS side that flag flips isUiAvailable false, which triggers enforceBuildAvailability() to actively tear down published state — clearing publishingEnabledKey, removing publicPaykitBolt11 and its hash/expiry, and raising cleanup-pending flags. Shipping that untested inside a release cut would be a materially worse problem than the one it solves.

[ovitrif]

utAck