6c769ed86c
## Issue Addressed Update Information in Lighthouse Book ## Proposed Changes - move Validator Graffiti from Advanced Usage to Validator Management - update API response and command - some items that aren't too sure I put it in comment, which can be seen in raw/review format but not live ## Additional Info Please provide any additional information. For example, future considerations or information useful for reviewers. Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com>
45 lines
2.8 KiB
Markdown
45 lines
2.8 KiB
Markdown
# Release Candidates
|
|
|
|
[sigp/lighthouse]: https://github.com/sigp/lighthouse
|
|
[sigp/lighthouse/releases/latest]: https://github.com/sigp/lighthouse/releases/latest
|
|
[sigp/lighthouse/releases]: https://github.com/sigp/lighthouse/releases
|
|
[`v1.4.0-rc.0`]: https://github.com/sigp/lighthouse/releases/tag/v1.4.0-rc.0
|
|
[`v1.4.0`]: https://github.com/sigp/lighthouse/releases/tag/v1.4.0
|
|
|
|
From time-to-time, Lighthouse *release candidates* will be published on the [sigp/lighthouse]
|
|
repository. Release candidates are previously known as Pre-Releases. These releases have passed the usual automated testing, however the developers would
|
|
like to see it running "in the wild" in a variety of configurations before declaring it an official,
|
|
stable release. Release candidates are also used by developers to get feedback from users regarding the
|
|
ergonomics of new features or changes.
|
|
|
|
Github will clearly show such releases as a "Pre-release" and they *will not* show up on
|
|
[sigp/lighthouse/releases/latest]. However, release candidates *will* show up on the
|
|
[sigp/lighthouse/releases] page, so **please pay attention to avoid the release candidates when
|
|
you're looking for stable Lighthouse**.
|
|
|
|
From time to time, Lighthouse may use the terms "release candidate" and "pre release"
|
|
interchangeably. A pre release is identical to a release candidate.
|
|
|
|
### Examples
|
|
|
|
[`v1.4.0-rc.0`] has `rc` in the version string and is therefore a release candidate. This release is
|
|
*not* stable and is *not* intended for critical tasks on mainnet (e.g., staking).
|
|
|
|
However, [`v1.4.0`] is considered stable since it is not marked as a release candidate and does not
|
|
contain `rc` in the version string. This release is intended for use on mainnet.
|
|
|
|
## When to use a release candidate
|
|
|
|
Users may wish to try a release candidate for the following reasons:
|
|
|
|
- To preview new features before they are officially released.
|
|
- To help detect bugs and regressions before they reach production.
|
|
- To provide feedback on annoyances before they make it into a release and become harder to change or revert.
|
|
|
|
There can also be a scenario that a bug has been found and requires an urgent fix. An example of incidence is [v4.0.2-rc.0](https://github.com/sigp/lighthouse/releases/tag/v4.0.2-rc.0) which contains a hot-fix to address high CPU usage experienced after the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12<sup>th</sup> April 2023. In this scenario, we will announce the release candidate on [Github](https://github.com/sigp/lighthouse/releases) and also on [Discord](https://discord.gg/cyAszAh) to recommend users to update to the release candidate version.
|
|
|
|
## When *not* to use a release candidate
|
|
|
|
Other than the above scenarios, it is generally not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). To test new release candidate features, try one of the testnets (e.g., Goerli).
|
|
|