Repository navigation
chore: prepare 3.0.1 release - #1512
piotr-iohk wants to merge 3 commits into
Conversation
 [Low impact] The preparation changes appear safe to merge after the stated release gates are complete. SummaryPrepares version 3.0.0, build 193, and consolidates 108 release-note fragments into
Acknowledged release work from Reviews (1) · Last reviewed commit: "chore: validate android rc2 preparation" · Reviewed by Greptile |
Regtest APKDownload bitkit-dev-debug universal APK (expires in 30 days). |
3.0.0 (RC2) — automated release gateRechecked 2026-10-19 12:55 CEST. SUCCESS for the completed automated workflow gates on exact store revision Verified runs
Coverage and run historyNative UI attempt 2 report: 267 cases, 263 passed, 4 skipped, 0 failed. The skipped cases are Local E2E passed all seven shards. Staging passed Pubky/Paykit, transfer, multi-address and hardware-wallet shards. Migration passed RN v1.1.6 restore/upgrade and native 2.5.0 restore/upgrade. Production artifacts were built and verified: APK package/version/signatures, AAB signature, native symbols and checksums. Android store build remains 3.0.0 (193). Cancelled duplicate runs, pre-undraft skipped workflows, skipped report jobs and skipped retarget helpers are not counted as passing tests; their successful replacements on this same commit are linked above. The historical Release recordPreserved 3.0.0 GitHub draft · Twin release PR RC1 drafts and No RC2 automated workflow gate remains pending or failed after the successful replacements/reruns above. This records automation, not a new manual-QA or store-approval sign-off. Planned sequence remains coordinated 3.0.0 publication after iOS approval, then 3.0.1 submission after validation. No merge, submission, publication, branch/tag change or build was performed by this audit. |
jvsena42
left a comment
jvsena42
left a comment
There was a problem hiding this comment.
Reviewed as a release against v2.5.0, the last release tag on master's lineage. v2.5.1 is a hotfix side branch and v2.6.0 an unpublished RC1. No findings.
Checked:
- Version: 3.0.0 / 193, above v2.6.0 (192), v2.5.1 (191) and v2.5.0 (190).
app/build.gradle.ktsis the only version source. OutsideCHANGELOG.mdandchangelog.d, the diff against mastereb32cdd71is the version bump alone. - Changelog: 108 fragments consumed, and
changelog.d/nextandhotfixhold only.gitkeep. I matched all 139 PRs merged since v2.5.0 against the 3.0.0 section. Each one has its own entry, an entry under its issue number, is chore/ci/test/docs, or was already listed under 2.5.0. With the 3.0.0 block removed, the file is byte-identical to v2.5.1's apart from the new[3.0.0]compare link, so the 2.5.1 section is preserved. #1510 is excluded and no bullet describes it. Default flips match their entries: PaykitPAYKIT_ENABLED_KEY ?: true(#1345), and USDT is still opt-in (usdtPreferencedefaults to UNDECIDED). - Dependencies since v2.5.0: bitkit-core 0.5.14 → 0.8.0-rc6, paykit rc51 → rc77, ldk-node rc.66 → rc.74, vss unchanged. The v2.5.1 hotfix's ldk-node rc.66.1 security fix is carried by rc.72 (#1475) and later. The release resolves core and paykit from the registry; mavenLocal and the local AAR are debug or opt-in only.
- Release build: the new USDT defaults all point at
https://bitkit.to/v1/usdt/..., and no localhost or staging host was added toapp/src/mainoutside the E2E paths. - Twin parity with synonymdev/bitkit-ios#956: same bitkit-core, ldk-node, paykit and vss pins. Changelog differences are platform items, plus the iOS snapshot predating its #948/#950/#953 counterparts of #1506/#1507/#1509, as its body states.
- Device: no runtime diff from master in this PR. CI's migration, e2e and upgrade jobs are the runtime evidence.
CI at 19449fb: unit, lint and migration (2.5.0 native upgrade/restore, v1.1.6 RN upgrade/restore) are green. E2E local shards lightning_security, onchain_boost_receive_widgets, send and multi_address_local are still pending, and E2E Staging and the UI tests are still running.
Device gate (partial): 19449fb — no device check needed; approval waits on the pending E2E shards above.
talosmachina
left a comment
talosmachina
left a comment
There was a problem hiding this comment.
No findings. Release prep for 3.0.0 (build 193): version bump and 108 changelog fragments consolidated into CHANGELOG.md. Reviewed 19449fb, full tier, reasoned from the code and CI (no Bitkit branch build here).
What I checked, and 3 candidates I ruled out
- App code matches master
eb32cdd71: the only non-changelog change isapp/build.gradle.kts(versionCode 193, versionName 3.0.0); 193 is above the tagged v2.6.0 (192) and v2.5.1 (191). - All 108 deleted
changelog.d/nextfragments appear in the 3.0.0 section (first 60 chars of each matched); no PR number is duplicated in it;changelog.d/nextkeeps only.gitkeep. - Released sections 2.5.0 and older are byte-identical apart from the compare-link footer; 2.5.1 matches its tag's text.
- Ruled out: a trailing blank line added at EOF of both files (
git diff --check), cosmetic.
CI: build, lint, detekt, migration-plan and four migration scenarios green; e2e-tests-local - onchain_boost_receive_widgets still running when reviewed.
Merge confidence: 4/5, e2e was not finished on this head.
![ovi-reviewer[bot]](https://avatars.githubusercontent.com/in/4862686?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: ✅ Approve
Posted as a comment: not every planned case passed.
Review: diff, 110 files, full review of this PR. I found no defects.
- All 108 consumed fragments appear once each in the 3.0.0 section, word for word, with only the #1481 corrections; the 2.5.1 and older sections are unchanged.
- @jvsena42's review at this head covers the version order, dependency pins and release hosts; I have nothing to add there.
QA for 19449fb:
No device case: the QA notes list none, and this PR changes no app code against master eb32cdd.
CI at this head:
- E2E Migration passed: native upgrade and restore from 2.5.0, React Native upgrade and restore from v1.1.6.
- Release build passed.
- E2E passed on all shards.
- UI Tests failed one test,
TxBumpingTests.testBumpFeeByRbf: the regtest deposit was not visible after the test's fixed 15 s wait and single sync (balance 0 of 100000). - E2E Staging passed.
- No run covers an upgrade from 2.5.1, the latest public release; it stays open on this PR's release checklist.
Pair PR synonymdev/bitkit-ios#956 matches at synonymdev/bitkit-ios@59278ad: the same 3.0.0 cut, with the iOS pairs of the USDT, backup and translation fixes this PR includes, and the same deferral of the profile-deletion fix.
jvsena42
left a comment
jvsena42
left a comment
There was a problem hiding this comment.
Approving at 19449fb. The code review from my earlier comment stands: no findings against v2.5.0, the v2.5.1 hotfix's ldk-node fix is carried by rc.74, the changelog is complete and history is preserved, and dependency pins match synonymdev/bitkit-ios#956.
CI at 19449fb: all seven E2E local shards, E2E Staging (dispatch), E2E Migration (2.5.0 native upgrade/restore, v1.1.6 RN upgrade/restore), CI, lint and the Release build are green. The dispatched UI Tests run was still in progress when I posted. Check its result before merge.
Device gate: 19449fb — no device check needed (no runtime diff from master; CI is the runtime evidence); perf: not relevant to this PR's diff; l10n: no UI text changed.
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
6e4bc01
19449fb to
6e4bc01
Compare
|
RC3 validation runs on the signed candidate head (pending runs are not pass evidence):
Production artifact build is waiting for the protected release-environment approval. This API session cannot approve it. RC2 remains preserved under |
There was a problem hiding this comment.
Verdict: ✅ Approve: no findings, and all five cases passed at 6e4bc01.
Findings: none.
Delta since our review at 19449fb: diff. The head is one signed preparation commit on master 402aecb, which carries 12 PRs merged since the RC2 cut. Against master, the commit changes only the build number (194) and the changelog.
- The 9 new 3.0.0 lines match their fragments word for word. Every product PR merged since the RC2 cut has a line; #1562 extends the cancel feature that the #1551 line already describes.
- All 117 consumed fragments appear once each. Apart from the date and those 9 lines, the 3.0.0 text is RC2's.
- Native pins: Paykit
0.1.0-rc77to0.1.0(#1555) and ldk-noderc.74torc.76(#1532). bitkit-core and vss are unchanged.
QA for 6e4bc01:
Tested on two Android 15 emulators with a dev debug build of this head on regtest, with staging Blocktank and the staging homeserver. Test 4 also used a dev build of v2.5.1, and Test 5 the bitkit-docker USDT fixture.
- Tests 1, 2, 3 and 5: focus areas from this PR's release checklist. A later merge touched Tests 1 to 3 after their last device run, and Test 5 had no device run.
- Test 4: the 2.5.1 upgrade that our RC2 review left open.
Test 1: Pubky sign-in link on a cold start ✅ A fresh sign-in link opened the stopped app. After the PIN, the "Loading Your Pubky Profile" toast stayed until Authorize opened, and Authorize reached the success screen.
- Toast: the PIN went in while the saved session was still restoring. The link waited 5 s for the restore, with the toast and its spinner on screen for that time, then the sheet showed
gate.testwith READ, WRITE. - Approval: Authorize and the PIN reached
PubkyAuthOK. A requester built on@synonymdev/pubky0.14.0 receivedapprovedfrom the wallet's key with/pub/gate.test/:rw. - Earlier unlock: a first run, unlocked after the restore had finished, opened the sheet at once and also reached
PubkyAuthOK. - Why re-run: #1510 changed the session-restore retry and the deferred restore, and #1555 swapped the native Paykit. Both landed after @ovitrif's sign-in check at master 722c824.
t1-signin-cold-start.2x.mp4 |
Test 2: Payment link while a sign-in is pending ✅ In all three orders, the Authorize sheet opened first, and Send opened with 10 000 sats after back.
- Sign-in, then
bitcoin:, on the PIN pad: Authorize first, then Send (Queuing 'deeplink' scan after a sign-in link). bitcoin:, then sign-in, on the PIN pad: Authorize first, then Send (Queuing 'deeplink' sign-in link first).bitcoin:over the open Authorize sheet: the sheet stayed, and Send opened after back.- Log:
Replacing deferred scanappears in no run. Each sign-in used a link that had not been opened before.
t2-signin-second-link.2x.mp4 |
Test 3: Delete profile ✅ Delete showed progress with Cancel and Save dimmed. Profile onboarding appeared 20 s after confirming, and the profile stayed gone after reopening and after a relaunch.
- Progress: after Yes, Delete, the pill showed a spinner, and Cancel and Save were dimmed with their labels visible.
- Timing: contacts were deleted 3 s after confirming, the secret key was removed at 17 s, and onboarding showed at 20 s.
- After: reopening Profile showed onboarding. After a force-stop and relaunch, the header read "Your Name". The log has no crash, ANR or uncertain-write wait.
- Why re-run: the last device pass was at #1510's head 98cab12. That was before it merged with the sign-in and backup fixes, and before Paykit 0.1.0.
- Not driven: the journey's 62-contact repeats. This profile had no contacts. The 62-contact timings are @jvsena42's samples at f22714b.
t3-delete-profile.2x.mp4 |
Test 4: In-place upgrade from 2.5.1 ✅ A 2.5.1 wallet with a Blocktank channel kept its 277 241 sats, its channel and its activity after this build was installed over it. It then sent on-chain and received over Lightning.
- Before, on 2.5.1: a received deposit, an on-chain send and a Transfer to spending opened channel
1cc8ff62…. On-chain held 207 849 sats and Lightning 69 392. - After, on 3.0.0 (194): the node started with the same 207 849 and 69 392 sats. The channel was ready and usable, and the three activities were kept.
- Payments: the upgraded wallet sent 15 000 sats on-chain ("Bitcoin Sent"). It also received 5 000 sats over the migrated channel ("Received Instant Bitcoin"). No crash or ANR.
- Why: E2E Migration at this head covers upgrades from 2.5.0 and v1.1.6 only. 2.5.1, the latest public release, ships ldk-node
rc.66.1. Our RC2 review left this upgrade open.
t4-upgrade-from-2.5.1.2x.mp4 |
Test 5: Pending USDT payment survives a restore ✅ A pending USDT payment for a contact's request still blocked a second payment after the payer's wallet was reset and restored from its recovery phrase.
- Setup: PayeeB requested $5.00 from contact PayerA, USDT only. PayerA paid it while the fixture held the bundler, so the payment stayed at "Payment submitted". The wallet backup ran after the payment was recorded.
- Before the restore: Continue on the same request showed "A payment is still pending. Wait for confirmation before sending again."
- After Reset and restore: the backup restored the USDT payments and the request came back. It first opened on its review screen with Swipe To Pay, which was not swiped, then moved to the amount step. There, Continue showed the same message. The payer still held 25.00 USDT, and its account had sent one operation.
- Which check blocked it: the restored transfer record, still Pending, refused the quote. The request-level guard that #1528 changed comes after the quote and was not reached.
- After the hold: released after about 13 minutes, the held operation failed the fixture bundler's re-check. The app then marked that transfer Failed and allowed the request again, and the new payment completed once ("USDT Sent", 25.00 to 19.17 USDT).
- Not driven: several restored attempts for one request, the case #1528 changed. The UI cannot stage overlapping restores, and
PaykitUsdtPaymentRepoRecoveryTestcovers it.
t5-usdt-restored-attempt.2x.mp4 | t5-after-failure-paid-once.2x.mp4 |
Not driven here:
- Electrum drop and rebroadcast (#1532): @jvsena42's device results on rc.76 stand. Since then, #1559 and #1562 only added the cancel-release code to
LightningService,LightningRepoandOnchainSendAttemptStore, and changed no existing send or broadcast line. His report leaves the TLS-handshake stall during a send unrun. - Proven on their own PRs, untouched since: #1558, #1559 and #1562 (cancel expired payment), and the support details of #1528.
- No device report: the busy-lock backup retry of #1552. Its unit tests cover it.
CI at this head: CI, Lint, E2E (7 shards), E2E Staging (including pubky_paykit), E2E Migration and Release pass.
- The first UI Tests dispatch failed two tests. The second at this head passed.
TxBumpingTests.testBumpFeeByRbfgotOnchainSendOutcome.Unknownfrom the regtest broadcast instead ofAccepted. That is a different failure from RC2's funding check, and it did not repeat on the rerun.CalculatorWidgetInputTest.fiatInputViaNumberPadUpdatesBtcAndPersistsWidgetStatetimed out. It fails the same way in recent master runs.
Pair PR synonymdev/bitkit-ios#956 matches at synonymdev/bitkit-ios@040374e: the same RC3 cut, with bitkit-core 0.8.0-rc6, ldk-node rc.76, Paykit 0.1.0 and vss 0.5.23. Its changelog pairs the RC3 lines for profile deletion, the sign-in sheet, restored USDT payments, the second link, cancelling an expired payment and USDT address sharing. It has no line for the Electrum reconnect that ldk-node rc.76 also brings to iOS, or for the backup retry while Paykit is busy.
3.0.1 preparation and validationUpdated 2026-10-19 12:44 CEST. Production build 195 and signed Completed checks on the built revision
The original full native UI run remains recorded as failed because staging regtest fixture funding failed. The focused unchanged-revision rerun passed both UTXO-selection tests. It is not a replacement full-suite pass; the 4 full-suite skips, including CPFP, remain skips. Documentation-only follow-upSigned commit
This compares the release snapshots directly, avoiding noise from their divergent preparation histories. No changelog entry text, application code, dependency, version or build setting changed. Comparison against the built tag is empty outside Drafts and artifactsCurrent 3.0.1 draft and changelog · Twin PR All four GitHub release drafts remain unpublished. Every release tag is unchanged. Android 195 APKs/symbols/checksums and the iOS 202 TestFlight build are unchanged; no AAB is attached to the 3.0.1 Android draft. The fixed tag review findings have been answered and resolved. Remaining release gates
No branch merge, store submission/publication, GitHub release publication or updater change was performed. |
jvsena42
left a comment
jvsena42
left a comment
There was a problem hiding this comment.
Delta review since my approval at v3.0.0-rc2: 12 merged PRs plus the rc3 and 3.0.1 metadata commits. No HIGH/MEDIUM. One LOW (tag and changelog link) is inline.
Checked and clean:
- Version: 3.0.1 is above every tag on both lineages (195 > 194/193/192/191).
- Changelog: every fragment is consumed, every user-facing PR merged since rc2 has a line, the 2.5.1 section is preserved, and nothing flag-gated is described.
- Dependencies: pins match synonymdev/bitkit-ios#956 (bitkit-core 0.8.0-rc6, ldk-node 0.7.0-rc.76, paykit 0.1.0, vss 0.5.23). ldk-node rc.76 changes only
electrum.rs: it replaces a broken client and retries a broadcast once within the deadline, and onlynon-finalmaps to Rejected. lightning 0.2.7 is kept, so the v2.5.1 fix is carried, and there's no persisted-format change. - Cancel-expired release (#1559/#1562 and the iOS pair): it forces a sync and refuses when the wallet knows any candidate. The approval is written before the proof is removed, and the release txid is saved before broadcast. It adds only confirmed extra coins, at a fee above every candidate's, and declining the PIN leaves the guard in place.
- USDT replacement guard and locked-link QuickPay suppression: traced, clean.
- Defaults: no flag defaults flipped, and no debug hosts in the delta.
Release precondition, not a finding: paykit 0.1.0 drops the 5-minute uncertain-write cooldown and relies on Homeserver 0.16.2+ with GCS to refuse late writes, without checking the server version. Confirm the production homeserver(s) run it before shipping.
Not approving yet: the migration and e2e jobs are still pending at this head. I'll approve once they're green.
Device gate: no device check needed (version and changelog only over RC3; each product PR was gated on its own PR); perf: not relevant; l10n: no UI text changed in this commit range.
jvsena42
left a comment
jvsena42
left a comment
There was a problem hiding this comment.
Approving at dba2a21. CI is green at this head: all seven e2e-local shards, E2E Migration (2.5.0 native upgrade/restore, v1.1.6 RN upgrade/restore), lint, detekt, build and Release.
This approval stands with one LOW open: the [3.0.0] compare link and the moved v3.0.0 tag. Fix it here or in a follow-up, your choice, and reply on the thread with which.
The homeserver precondition from my earlier review still applies before shipping: paykit 0.1.0 needs Homeserver 0.16.2+ with GCS.
Device gate: dba2a21 — no device check needed (version and changelog only over RC3; each product PR was gated on its own PR); perf: not relevant; l10n: no UI text changed in this range.
There was a problem hiding this comment.
Verdict: ✅ Approve: no findings, and the upgrade from 3.0.0 passed at dba2a21.
Findings: none.
Delta since our review at 6e4bc01: diff, 2 files.
- Version: 3.0.1 (195). It reaches only the Support screen, the support and log text, and the updater's build comparison. No migration reads it.
- Changelog: the 9 RC3 lines moved word for word into the new 3.0.1 section. The 3.0.0 section is now RC2's text byte for byte, date included, and the 2.5.1 and older sections are unchanged.
- Tags:
v3.0.0andv3.0.0-rc2both resolve to 19449fb, andv3.0.1to dba2a21. So[3.0.0]spans only the RC2 cut, and[3.0.1]the RC3 fixes listed under it, which settles @jvsena42's tag thread. - Earlier device results: no app code changed since 6e4bc01, so Tests 1 to 5 of our review there stand.
QA for dba2a21:
Tested on two Android 15 emulators on regtest, with staging Blocktank and the staging homeserver. The wallet under test started on the CI dev build of v3.0.0 (19449fb), and a dev build of this head was installed over it. The second emulator held the contact.
Test 1: In-place upgrade from 3.0.0 (193) ✅ A 3.0.0 wallet with a channel, a Pubky profile and a paid contact kept all of them after this build was installed over it. It then paid that contact and received over Lightning.
- Before, on 3.0.0 (193): a 300 000 sat deposit, then Transfer to spending opened channel
1afdf978…. Profile PayerA added contact PayeeB, both sides, and paid PayeeB 20 000 sats. Savings held 177 276 and spending 100 000. - After, on 3.0.1 (195): Support read 3.0.1 (195). The node started with the same 177 276 and 100 000, and the channel was ready and usable. The three activities were kept, the payment still "Sent to PayeeB", and so were the profile and the contact.
- Paykit: the log shows Paykit 0.1.0 restoring the private link to PayeeB that 3.0.0 had stored, and the next 15 000 sat payment to PayeeB going over it. PayeeB's wallet showed it received. The 3.0.0 payment had used PayeeB's public endpoint, while the link was still being set up.
- Lightning: 5 000 sats arrived over the upgraded channel ("Received Instant Bitcoin"). The post-upgrade log has no crash or ANR.
- Why:
v3.0.0now names RC2 build 193, the store submission, so 3.0.1 upgrades from it. Paykit rc77 to 0.1.0 and ldk-node rc.74 to rc.76 lie between them. E2E Migration covers upgrades from 2.5.0 and v1.1.6, and our 6e4bc01 Test 4 covered 2.5.1.
t1-part1-on-3.0.0.2x.mp4 | t1-part2-upgrade-to-3.0.1.2x.mp4 |
Not driven here:
- Final production-build smoke QA from the QA notes: the production build runs on mainnet, and our runs use test funds only. It stays on the release checklist.
CI at this head: CI, Lint, E2E (7 shards), E2E Staging, E2E Migration and Release pass.
- The full UI Tests run failed one test,
UtxoSelectionTests.testUtxoSelectionAlgorithms, on the staging regtest mining request, as @piotr-iohk's triage found. - The CoreServiceIntegration rerun, whose suite includes that test, passed.
Review covered the delta above; Test 1 drove its only runtime change, the version text.
Pair PR synonymdev/bitkit-ios#956 matches at synonymdev/bitkit-ios@2eceedb: 3.0.1 (202) on its RC3 cut, the same 3.0.1 split with the 3.0.0 section back to RC2's text, and v3.0.0 there also resolves to its RC2 commit 59278ad. Its 3.0.1 notes still have no line for the Electrum reconnect that ldk-node rc.76 brings, or for the backup retry while Paykit is busy.
Release automation overviewVerified 2026-10-19 12:55 CEST against the built/tagged revisions. 3.0.0 — RC2, to publish first
3.0.1 — follow-up release
These statuses concern the actual built revisions. Any automatic checks on the later comparison-link-only commits are separate. Manual release sign-off, store approvals and publication remain separate gates. |
There was a problem hiding this comment.
Verdict: ✅ Approve: no findings, and no app code changed since our dba2a21 review.
Findings: none.
Delta since our review at dba2a21: diff, 1 file.
[3.0.1]link:v3.0.0(19449fb) is not an ancestor ofv3.0.1(dba2a21). The old three-dot page diffed from their merge base and showed 183 files, 108 of them fragments that both cuts consumed. The two-dot page shows the 75 files that changed between the RC2 store build and 3.0.1.[3.0.0]link:v2.5.1is not an ancestor ofv3.0.0either, and both forms show the same 699 files.- Tags: unchanged.
v3.0.0andv3.0.0-rc2resolve to 19449fb,v3.0.0-rc3to 6e4bc01 andv3.0.1to dba2a21.
QA for fba36fd:
No device case: the QA notes list none for this change, and it changes no app behaviour. The tree outside CHANGELOG.md equals dba2a21, so Test 1 of our dba2a21 review, the upgrade from 3.0.0, and Tests 1 to 5 of our 6e4bc01 review stand.
Not driven here:
- Final production-build smoke QA from the QA notes: the production build runs on mainnet, and our runs use test funds only. It stays on the release checklist.
CI at this head: CI, Lint, E2E (7 shards) and E2E Migration pass. E2E Staging, UI Tests and Release did not run here; their dba2a21 results in our earlier review carry, since the tree outside CHANGELOG.md is identical.
Review covered the delta above; no device case drove it, since it changes only two changelog links.
Pair PR synonymdev/bitkit-ios#956 matches at synonymdev/bitkit-ios@dfc3849: the same two links move to two-dot, and its v3.0.0 resolves to its RC2 commit 59278ad and v3.0.1 to 2eceedb.
jvsena42
left a comment
jvsena42
left a comment
There was a problem hiding this comment.
Approving at fba36fd. The only commit since my approval changes two compare links in CHANGELOG.md. v3.0.0 resolves to RC2 19449fb again, so [3.0.0] runs from v2.5.1 to RC2 and [3.0.1] from RC2 to 3.0.1, with the RC3 fixes listed only under 3.0.1. Two-dot compares are right, since the lines have diverged. My LOW is fixed.
CI at fba36fd: green (build, lint, all e2e-local shards, E2E Migration 2.5.0 and v1.1.6).
Device gate: fba36fd — no device check needed (changelog only over the tagged 3.0.1 build); perf: not relevant; l10n: no UI text changed.
This branch was successfully deployed
7 participants
Prepares 3.0.1 (195) from the already-cut RC3 source, without adding newer master changes. Twin: synonymdev/bitkit-ios#956.
Description
Advances the marketing version from 3.0.0 to 3.0.1 and the build to 195.
Includes the agreed RC3 fixes: Electrum recovery, expired payment cancellation, Paykit 0.1.0, profile-deletion synchronization, Pubky sign-in recovery, restored-USDT protection and address sharing.
Splits the 3.0.1 fixes into their own changelog section; preserves every 3.0.0 RC2 entry and Ovi's corrections.
Signed preparation commit
dba2a2177d6f671d96f377206e5dc50db1cc59c6is Verified on GitHub. New signed tagv3.0.1identifies this revision.Preserves
v3.0.0-rc2,v3.0.0-rc3and RC1v2.6.0. At Piotr’s request, signedv3.0.0now points to the exact RC2 store revision (build 193); signedv3.0.1still points to this new candidate. The existing unpublished candidate draft is reused for 3.0.1.Signed documentation follow-up
fba36fd43fcea003f1fac5d1e306b9bb89359809fixes the 3.0.0 and 3.0.1 comparison URLs to direct two-dot comparisons. No tags or build artifacts moved;v3.0.1still identifies built revisiondba2a2177d6f671d96f377206e5dc50db1cc59c6.Design
N/A — no UI changes in this preparation.
Preview
N/A
QA Notes
Journeys
No product changes relative to RC3; merged product fixes retain their journeys.
Manual Tests
Final 3.0.1 production-build smoke QA remains required. Prior RC3 evidence is retained but is not final-build sign-off.
Automated Checks
Updated 2026-10-19 12:44 CEST. The completed runs below validate built/tagged revision
dba2a2177d6f671d96f377206e5dc50db1cc59c6(3.0.1 build 195).The original full native UI run remains recorded as failed because staging regtest fixture funding failed. The focused unchanged-revision rerun passed both UTXO-selection tests. It is not a replacement full-suite pass; the 4 full-suite skips, including CPFP, remain skips.
The latest signed PR commit
fba36fd43fcea003f1fac5d1e306b9bb89359809changes only two comparison URLs inCHANGELOG.md. Its parent is the built/tagged revision above; the full tree comparison outsideCHANGELOG.mdis empty. Runtime code, dependencies, version/build metadata and production binaries are unchanged. New automatic checks on this documentation-only head are separate from the completed build validation; no manual rerun or rebuild was dispatched.Remaining release work
Reused draft: https://github.com/synonymdev/bitkit-android/releases/tag/untagged-53b0d75f4bd557ba937a No release PR merge, GitHub publication, store submission/rollout or updater change is part of this task.