From 242a2486f16678accda9c50843f50aee919be81f Mon Sep 17 00:00:00 2001 From: Emily Furlong Date: Fri, 26 Sep 2025 11:20:00 +0200 Subject: [PATCH] Update release-process.md I've made some small edits to reflect the new protocol upgrades governance process --- src/release-process.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/src/release-process.md b/src/release-process.md index 3435c98..c1a6c55 100644 --- a/src/release-process.md +++ b/src/release-process.md @@ -13,11 +13,12 @@ Protocol upgrades run on a regular schedule. This helps resolve some of the chal The thousand-yard view of our release process is as follows: 1. Features are developed according to a stable-trunk development model. -2. Features are deployed to an Alphanet for initial acceptance testing. +2. Features are deployed to an Alphanet for initial acceptance testing. The Developer Advisory Board should be kept in the loop. 3. If the feature works on Alphanet, it gets deployed to a Betanet for additional testing and upgrade process validation. -4. If the feature works on Betanet, it gets deployed to the Sepolia Testnet for governance review. -5. If governance passes, the feature is deployed to mainnet. +4. As soon as code is frozen, the upgrade proposal can be posted to the forum and the Developer Advisory review period starts (7d). +5. If the feature works on Betanet, it gets deployed to the Sepolia Testnet for stakeholder veto period (7d). +6. If governance passes, the feature is deployed to mainnet. You will need to budget roughly 6 weeks from the time your feature is code-complete to the time it is deployed on mainnet, exclusive of audit time. Working backwards from mainnet deployment, the rough timeline is as follows: @@ -25,12 +26,13 @@ mainnet, exclusive of audit time. Working backwards from mainnet deployment, the | Time | Activity | |-----------|---------------------------------------------------| | T | Mainnet Activation | -| T-1 week | Governance veto starts | | T-2 weeks | Cut mainnet release, distribute to node operators | -| T-3 weeks | Governance vote starts | -| T-4 weeks | Governance review starts | +| T-3 weeks | Stakeholder veto period starts | +| T-3 weeks | Sepolia deployment | +| T-4 weeks | Post upgrade proposal to forum, DAB review starts | | T-4 weeks | Betanet deployment and acceptance testing | | T-5 weeks | Alphanet deployment and acceptance testing | +| T-6 weeks | Developer Advisory Board looped in for review | | T-6 weeks | Feature is code-complete | Check out the [release calendar](./release-calendar.md) for more information on the schedule. @@ -69,7 +71,7 @@ tests. See the [Acceptance Testing](./acceptance-testing/index.md) document for ## Testnet The Sepolia Testnet is the first public deployment of protocol upgrades. This allows ecosystem partners to test the -upgrades in a stable environment and runs in parallel with the governance process. Unlike Alphanets and Betanets, +upgrades in a stable environment and runs in parallel with the 7 day stakeholder veto period. Unlike Alphanets and Betanets, the Testnet directly impacts external users and applications and is considered "production." TO provide sufficient time for infrastructure providers to upgrade their systems, Testnet releases must be cut at @@ -79,9 +81,5 @@ least 1 week in advance of any hardfork activation. should target having your features deployed to the Alphanet and Betanet right before the gov cycle at the very latest. For example: -| Governance Cycle | Latest Alphanet | Latest Betanet | -|----------------------------|------------------|-----------------| -| Cycle 34 (Feb 27 - Mar 13) | Badger (Feb 17) | Balrog (Feb 24) | -| Cycle 35 (Mar 20 - Apr 2) | Cheetah (Mar 10) | Cupid (Mar 17) | -See the [release calendar](./release-calendar.md) for the most up-to-date information on the release schedule. \ No newline at end of file +See the [release calendar](./release-calendar.md) for the most up-to-date information on the release schedule.