mirror of
https://github.com/anza-xyz/agave.git
synced 2026-05-01 07:12:39 +02:00
Page:
Backport Guidelines
Pages
2024 01 02 Testnet Rollback and Restart
2024 08 26 Testnet Restart
2024 10 09 Testnet Rollback and Restart
2024 10 16 Testnet Rollback and Restart
2024 12 11 Testnet Restart
2025 01 14 Testnet Rollback and Restart
2025 07 02 Testnet Rollback and Restart
2025 07 03 Devnet rollback and restart
2025 10 01 Testnet rollback and restart
2025 12 03 Testnet rollback and restart
2025 12 06 Testnet rollback and restart
2025 12 11 Testnet rollback and restart
2026 01 22 Testnet Restart
Agave Transition
Agave v2.0 Transition Guide
Backport Guidelines
Debugging Consensus Failures
Feature Gate Activation Guidelines
Feature Gate Activation Process
Feature Gate Activation Schedule
Feature Gate Setup Process
Feature Gate Tracker Schedule
General Debugging
Home
Incremental Snapshots
Learning Blockchain, Crypto, and Solana
Learning Rust
Snapshot Guide
v1.16 Release Schedule
v1.17 Release Schedule
v1.18 Release Schedule
v1.18 commits
v2.0 Release Schedule
v2.1 Release Schedule
v2.2 Release Schedule
v2.3 Release Schedule
v3.0 Release Schedule
v3.1 Release Schedule
v4.0 Release Schedule
v4.1 Release Schedule
No results
This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Agave Backport Review Guidelines
Code changes to Agave are normally made to the master branch. Bug fixes can be backported directly to the beta and stable branches if the benefit of doing so outweighs the risk. Backports must be approved by a member of the Backport Reviewers group.
Backports must:
- Fix a bug, or facilitate debugging of a known / suspected bug
- Be the smallest / simplest solution that can reasonably address the bug. Often a bug fix involves refactoring or code cleanup. In those cases the work should be done in at least 2 PRs:
- The smallest / simplest solution to the bug, which is eligible to be backported.
- The rest of the changes, which should not be backported.
- Ask the Backport Reviewers for feedback on your
masterPR if you're unsure about this criteria.
- Be merged to all newer branches first (master before beta, beta before stable).
- Have been run on a node on a suitable public cluster unless inappropriate to do so.
Backports to stable must:
- Be audited before being merged, if they modify a portion of the code that we typically audit
Criteria for reviewing backports:
- The severity of the bug being fixed
- How much complexity the change introduces
- How thoroughly the change has been tested
- If a new bug is introduced, how severe could it be, and how long until it will be recommended for mainnet-beta. Commits to the stable branch ship to mainnet-beta weekly, leaving very little opportunity to discover a newly introduced bug. Commits to the beta branch ship to mainnet-beta at the end of the stabilization cycle. Backports to beta late in the stabilization cycle carry more risk and should be reviewed more stringently.
- General
- Feature Gates
- Technical
- Policy
- Schedule
- Restart Instructions