Skip to content

Update release-process.md #68

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+10 −12
Open

Update release-process.md #68

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 10 additions & 12 deletions src/release-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,24 +13,26 @@ 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have a link or something that gives more background on the DAB and how to get in contact with them?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes! will work on a separate page on that that we can link to

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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what is that we mean here with the code being "frozen", and how it differs from the "Feature is code-complete" at T-6 weeks.

According with the SDLC, audits happen before the Alphanet deployment, and we aim to have no more code changes after the audits.

So I assume that the DAB review should start at T-6, and not T-4?

Note as well that Alphanet and Betanet testing is intended to surface faults that couldn't be detected without realistic usage. The DAB review is closer in spirit to the audit, and should happen in parallel with the same, so T-6.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the DAB review to start, we should have no more code changes. So if that's at T-6, that's a reasonable starting point. When I spoke to Seb he mentioned that for upgrades that touch the fault proof system we need to generate an absolute prestate hash which might happen a bit later, closer to the start of the deployment on Sepolia. The timeline probably depends a bit on the upgrade ...

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:

| 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 |
Comment on lines +30 to +31
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this right? My understanding was that the veto period starts 1 week before the mainnet activation?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can start it at any point after the DAB review. is complete - 1 week before mainnet activation is also ok. I was assuming the sooner the better

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see. I think it is common to look at this the other way, as in "what's the tightest schedule that can be run" in terms of going from code complete to activation.

| 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.
Expand Down Expand Up @@ -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
Expand All @@ -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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
See the [release calendar](./release-calendar.md) for the most up-to-date information on the release schedule.