meta: Add RELEASE.md #3224
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,94 @@ | ||
| # Rusk Monorepo Release Process | ||
|
|
||
| ## **1. Branching Strategy** | ||
|
|
||
| ### `master` Branch | ||
| - **Purpose:** Active development. | ||
| - **Policy:** | ||
| - All new features behind feature flags. | ||
| - Merged only after passing CI, integration tests, and approval. | ||
|
|
||
| ### `devnet` Branch | ||
| - **Purpose:** Weekly snapshots from `master` for early testing. | ||
| - **Policy:** Updated weekly, deploying directly to the Devnet environment. | ||
|
|
||
| ### Release Branches (`rusk-release-vX.Y`) | ||
| - **Purpose:** Stable releases for mainnet or testnet deployments. | ||
| - **Why We Need It:** | ||
| - **Hotfix Management:** Allows hotfixes to be applied without branching from tags. | ||
| - **Long-Term Support:** Enables long-term support and backporting of fixes. | ||
| - **Clear Release Tracking:** Provides a clear path for version progression. | ||
|
|
||
| - **Creation:** Every 1-3 months or as needed. | ||
| - **Hotfixes:** Created directly on the (affected) release branch. | ||
|
|
||
| --- | ||
|
There was a problem hiding this comment. I personally see no purpose of these separators, just make the file more cluttered, when viewing as MD rather than raw text. |
||
|
|
||
| ## **2. Tagging and Release Strategy** | ||
|
|
||
| ### Libraries | ||
| - `dusk-abi-vX.Y.Z` (rusk-framework release?) | ||
| - `dusk-core-vX.Y.Z` (rusk-framework release?) | ||
| - `dusk-wallet-core-vX.Y.Z` (rusk-framework release?) | ||
| - `w3sper.js-vX.Y.Z` | ||
|
|
||
| ### User-Facing Apps | ||
| - `explorer-vX.Y.Z` | ||
| - `rusk-wallet-vX.Y.Z` | ||
| - `web-wallet-vX.Y.Z` | ||
|
|
||
| ### Blockchain Node | ||
| - `rusk-vX.Y.Z` (node binary release) | ||
| - `rusk-framework-vX.Y.Z` (library releases for components such as ABI, core, wallet-core) | ||
|
|
||
| **Example:** `rusk-v1.2.3` | ||
|
|
||
| --- | ||
|
|
||
| ## **3. Release Lifecycle** | ||
|
|
||
| 1. **Day 0:** Create release branch `rusk-release-vX.Y` from `master`. | ||
| 2. **Day 1:** Deploy release to **Testnet**. | ||
| 3. **Day 7:** Release validated and stabilized in Testnet. | ||
| 4. **Day 10:** Finalize integration tests and prepare for mainnet deployment. | ||
| 5. **Day 14:** Community announcement and gradual provisioners upgrade. | ||
| 6. **Day 16:** Deploy `rusk-vX.Y.Z` to **Mainnet**. | ||
|
Comment on lines
+54
to
+55
There was a problem hiding this comment. Isn't "provisioner upgrade" the same of "deploy to mainnet"? What's the difference? There was a problem hiding this comment.
People already deploying the binary, but thinking about it it doesn't make a whole lot of sense since we'll specify an upgrade is active after a given block height into the future anyway if it's a protocol change. Maybe it makes sense to specify a minimum amount of time/blocks a protocol change needs to be activated. In terms of the dates mention, they're just examples. Feel free to suggest a different time frame. |
||
|
|
||
| --- | ||
|
|
||
| ## **4. Compatibility and Testing** | ||
|
|
||
| ### **Testing Phases** | ||
| 1. **Unit Tests:** Every PR must pass. | ||
| 2. **Integration Tests:** Wallet, SDKs, contracts, circuits. | ||
| 3. **Network Tests:** Simulate large-scale node clusters. | ||
| 4. **Compatibility Tests:** Ensure backward compatibility with old node versions. | ||
|
There was a problem hiding this comment. I would change "old node versions" to "previous cluster" |
||
|
|
||
| --- | ||
|
|
||
| ## **5. Release Artifacts** | ||
|
|
||
| - **Crates.io Packages:** For Rust libraries (`dusk-abi`, `dusk-core`, `dusk-wallet-core`, `rusk-wallet`). | ||
| - **NPM/JSR Packages:** For JavaScript libraries (`w3sper.js`). | ||
| - **Docker Images:** Published for node: default and archive feature. | ||
| - **GitHub Releases:** For `rusk-wallet`, `web-wallet`, `explorer`, `rusk`, and `rusk-framework`. | ||
| - **Svelte Builds:** Uploaded to production servers after integration testing. | ||
|
|
||
| --- | ||
|
|
||
| ## **6. Release Documentation** | ||
|
|
||
| - **GitHub Release Notes:** Each release includes: | ||
| - Summary of changes. | ||
| - Migration steps (if applicable). | ||
| - Framework upgrade details. | ||
| - **Changelog Management:** Use automated changelog generation from PR labels (`breaking-change`, `enhancement`, `bug-fix`). | ||
|
There was a problem hiding this comment. Just a note – for Web Apps, @kieranhall has investigated automated changelog generation some time ago. However, seems like we couldn't find a solution that suits our needs, given the current way we do the change log. We still quite often have merge conflicts, related to the changelog, so I am not against an automated solution. But we might need to discuss with the rest of the tech team and see if we can do something similar to what others are doing, so to integrate such solution for us too. |
||
|
|
||
| --- | ||
|
|
||
| ## **7. Environment Versioning Policy** | ||
|
|
||
| - **Local Development:** `X.Y.Z-dev` | ||
| - **Devnet:** `X.Y.Z-rc` | ||
| - **Testnet:** `X.Y.Z-beta` | ||
|
Comment on lines
+92
to
+93
There was a problem hiding this comment. Shouldn't the Devnet serve as the beta environment and the Testnet act as the Release Candidate? Since the Release Candidate is expected to be more stable than the beta, it seems more logical for it to be deployed on the Testnet. |
||
| - **Mainnet:** `X.Y.Z` | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit confused, especially with the 7. Environment Versioning Policy stating that testnet is beta (well, I think it should be RC, see the comments there).
If so, testnet should be for the rc branches, while the mainnet for the stable branches (rusk-release-vX.Y) only, no?