4.9 KiB
4.9 KiB
Release Issue Template
Lotus X.Y.Z Release
🚢 Estimated shipping date
<Date this release will ship on if everything goes to plan (week beginning...)>
✅ Release Checklist
Note for whoever is owning the release: please capture notes as comments in this issue for anything you noticed that could be improved for future releases. There is a Post Release step below for incorporating changes back into the RELEASE_ISSUE_TEMPLATE, and this is easier done by collecting notes from along the way rather than just thinking about it at the end.
First steps:
- Set shell variables vX.Y.Z
export X=1 && export Y=24 && export Z=3
- FFI: Fork a new branch (
release/lotus-vX.Y.Z
) from the filecoin-ffimaster
branch:git checkout master && git checkout -b release/lotus-v$X.$Y.$Z
- FFI: Tag the head of
release/lotus-vX.Y.Z
asvX.Y.Z-pre1
:git tag -a v$X.$Y.$Z-pre1 -m"release"
- Open and land a PR in lotus
master
that updates the FFI dependency tovX.Y.Z-pre1
as cut in the previous step - Fork a new branch (
release/vX.Y.Z
) frommaster
and make any further release related changes to this branch. If any "non-trivial" changes get added to the release, uncheck all the checkboxes and return to this stage. - Bump the version in
build/version.go
in themaster
branch tovX.Y.(Z+1)-dev
(bump from feature release) orvX.(Y+1).0-dev
(bump from mandatory release). - Run
make gen && make docsgen-cli
before committing changes
Prepping an RC:
- version string in
build/version.go
has been updated (in therelease/vX.Y.Z
branch) - run
make gen && make docsgen-cli
- Generate changelog using the script at scripts/mkreleaselog
- Add contents of generated text to lotus/CHANGELOG.md in addition to other details
- Commit using PR
- tag commit with
vX.Y.Z-rcN
- cut a pre-release here
Testing an RC:
-
Stage 0 - Automated Testing
- Automated Testing
- CI: Ensure that all tests are passing.
- Testground tests
- Automated Testing
-
Stage 1 - Internal Testing
- Binaries
- Ensure the RC release has downloadable binaries
- Upgrade our testnet infra
- Wait 24 hours, confirm nodes stay in sync
- Upgrade our mainnet infra
- Subset of development full archival nodes
- Subset of bootstrappers (1 per region)
- Confirm nodes stay in sync
- Metrics report
- Block validation time
- Memory / CPU usage
- Number of goroutines
- IPLD block read latency
- Bandwidth usage
- If anything has worsened significantly, investigate + fix
- Confirm the following work (some combination of Testground / Calibnet / Mainnet / beta users)
- Seal a sector
- make a deal
- Submit a PoSt
- (optional) let a sector go faulty, and see it be recovered
- Binaries
-
Stage 2 - Community Testing
- Test with SPX fellows
- Work on documentations for new features, configuration changes and so on.
-
Stage 3 - Community Prod Testing
- Update the CHANGELOG.md to the state that can be used as release note.
- Invite the wider community through (link to the release issue)
Stable Release
- Final preparation
- Verify that version string in
version.go
has been updated. - Verify that codegen is up to date (
make gen && make docsgen-cli
) - Ensure that CHANGELOG.md is up to date
- Merge
release-vX.Y.Z
into thereleases
branch. - Tag this merge commit (on the
releases
branch) withvX.Y.Z
- Cut the release here.
- Verify that version string in
Post-Release
- Merge the
releases
branch back intomaster
, ignoring the changes toversion.go
(keep the-dev
version from master). Do NOT delete thereleases
branch when doing so! - Update RELEASE_ISSUE_TEMPLATE.md with any improvements determined from this latest release iteration.
- Create an issue using RELEASE_ISSUE_TEMPLATE.md for the next release.
❤️ Contributors
See the final release notes!
⁉️ Do you have questions?
Leave a comment in this ticket!