Files
nym/documentation/docs/pages/operators/release-cycle.mdx
T
import this 9f08983077 [DOCs]: Operators rework to next.js (#4930)
* initialise operators guides v2

* new introduction page

* add variables csv and page

* add baseurl to allow short path

* add sandbox page

* added building from source page

* add binary pages

* add preliminary steps

* clean preliminary steps dir

* syntax edit

* syntax edit

* add configuration page

* create new proxy configuration page

* create new proxy configuration page

* create bonding.mdx page

* correct images path

* syntax edit

* add new validator setup page

* add api setup page

* add nyx configuration page

* add nym node and maintenance pages

* finish maintenance and add nymvisor conf page

* add manual upgrade page

* add nymvisor upgrade page

* add performance testing page and dir

* add node api check page

* add explore nym scripts page

* add testing pages

* fix menu issue by moving snippets to coomponents

* add all troubleshooting pages

* add general faq page

* add nym node faq page

* add nyx faq page

* revamp legal forum to community counsel and add all pages

* rewire relative paths to new structure

* simplify setup and remove lock file

* syntax fix

* rm package.json

* re add package.json, rm package-lock.json

* removed old books from commit

* address review comments

---------

Co-authored-by: mfahampshire <maxhampshire@pm.me>
Co-authored-by: mx <33262279+mfahampshire@users.noreply.github.com>
2024-10-24 13:58:35 +02:00

94 lines
7.2 KiB
Plaintext

import { Callout } from 'nextra/components'
# Release Cycle
Nym operator community is growing in quality and quantity. With node operators and developers joining the effort to make the Mixnet more robust and scalable, testing new features, sharing integration pull requests and generally taking an active part in Nym development, more transparency on the release cycle is required.
The core team therefore established a flow with different environments:
- ***local***: Developers use their local environments for feature building
- ***canary***: Nym internal testing environment managed by Qualtiy Assurance team (QA)
- [***sandbox***](sandbox.mdx): Public testnet, including testnet NYM token available in the [faucet](sandbox.mdx#sandbox-token-faucet)
- ***mainnet***: Nym Mixnet - the production version of Nym network
## Release Flow
Frequency of releases to mainnet is aimed to be every ~14 days. This time window is an optimal compromise between periodicity and quality assurance/testing, key factors playing an essential role in development.
| **Stage** | **Environment** | **Branch** | **Ownership** |
| :-- | :-- | :-- | :-- |
| development work | local/canary | feature branches | devs |
| cut and test release | canary | release branch | QA |
| bug fixing | canary | directly on release branch | QA & devs |
| put release on sandbox | sandbox | release -> master/develop | QA |
| promote release to mainnet after 3-5 days | mainnet | master | QA |
```ascii
▲ ▲
│ │
│ merge back into develop │
MAINNET ├─────────────────────────►│
easy │ │
autopromotion│ │
▲ │ │
│ │ │
│ │ │◄───────────────────────────────┐
│ │ │ │
└───release │ │ │
to x◄───────────────┐ │ │
sandbox ▲ │ │◄────────────────────────┐ │
│ ┌────────────► │ │ │
│ │ │ │ │ │
│ │ bug │ │ │ │
│ │ fix │ │◄─────────────────┐ │ │
│ │ │ │ │ │ │
│ │ │ │ M │ │ │
│ └────────────┤ │ I │ │ │
│ │ │ L │ │ │
│ └─────────x E │ │ │
│ release ▲ S │ │ │
^ │ cut │ T │ │ │
: │ --- │ O │ │ │
: │ fixed │ N │ │ │
: │ release │ E │ │ │
: │ every │ feature-bob3 │ │ │
: │ 14 days ├──────────────────┘ │ │
: │ │ │ │
: │ │ │ │
: │ │ feature-bob2 │ │
: │ ├─────────────────────────┘ │
: │ │ │
: │ │ │
: │ │ feature-bob1 │
: │ ├────────────────────────────────┘
: │ │
: │ │
:t │ │
:i │ │
:m │ │
:e │ │
master develop feature branches
ENVs
┌─────────┬────────┬──────────────────────────┬─────────────────────────────────┐
│mainnet │sandbox │ QA / canary │ development │
│ │ │ │ │
└─────────┴────────┴──────────────────────────┴─────────────────────────────────┘
```
### Changes & Collaboration
To track changes easily, builders and operators can visit one of the following:
- [*CHANGELOG.md*](https://github.com/nymtech/nym/blob/master/CHANGELOG.md): Raw changelog of merged feauters in Nym's monorepo, managed by devs and QA.
- [*Changelog page*](changelog.mdx): A detailed explanation, testing steps and updated summary of documentation changes, managed by devrels.
In case you want to propose changes or resolve some of the existing [issues](https://github.com/nymtech/nym/issues), start [here](https://github.com/nymtech/nym/issues/new/choose). If you want to add content to the Operators Guide, visit [this page](community-counsel/add-content.mdx).
<Callout>
Feature tickets need explicit (while concise) wording because that title is eventually added to the changelog. Keep in mind that bad ticket naming results in bad changelog.
If you want to run in the testing environment, follow our [Sandbox testnet](sandbox.mdx) guide.
</Callout>