You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Tracking: prepare and manage release_v4.8.3 branch #6957
This issue is to coordinate the creation and tracking of the release_v4.8.3 branch from develop.
Branch Details
Version: v4.8.3
Branch to create: release_v4.8.3
Base branch: develop
Tasks
Create release_v4.8.3 branch from develop
Push final PRs to release_v4.8.3 (e.g., version bump, changelog, fixes, features)
Perform QA and testing on release_v4.8.3
Merge release_v4.8.3 back to master when testing is complete
Tag GreatVoyage-v4.8.3(Ockham) on master and release
Merge master back to develop (if applicable)
Notes
Once the release_v4.8.3 branch is created, it will act as the staging area for all final updates and fixes for this release.
Any non-release-related changes should continue in develop.
For release QA, please include an in-place upgrade test from v4.8.2 using an existing production-like database, followed by restart recovery and continued synchronization. A mixed-version peer test between v4.8.2 and v4.8.3 would also be useful, comparing consensus-critical results such as block and transaction roots, receipts, and account state at fixed heights. This can catch database, serialization, or compatibility regressions that unit and API tests may miss.
Activity
SeriousCoding789 commentedon Sep 9, 2026
Please comment below with any bugs or feature requests you'd like considered for the next release.
9 remaining items
lxcmyf commentedon Sep 17, 2026
For release QA, please include an in-place upgrade test from v4.8.2 using an existing production-like database, followed by restart recovery and continued synchronization. A mixed-version peer test between v4.8.2 and v4.8.3 would also be useful, comparing consensus-critical results such as block and transaction roots, receipts, and account state at fixed heights. This can catch database, serialization, or compatibility regressions that unit and API tests may miss.