cerc-io/lotus
16
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 27 Wiki Activity
a59d83518d
lotus/documentation/misc/RELEASE_ISSUE_TEMPLATE.md
Phi a59d83518d Update release_issue_template 
Update release_issue_template.

- Changed some wrong links (links pointed to version.go in IPFS-repo)
- Removed `Create a discussion for this release`
- Removed "Prep the changelog using `scripts/mkreleaselog`, and add it to `CHANGELOG.md`" since this already has been captured in the first pre-release step. Left that you should make sure that the CHANGELOG is up to date.
2022-08-10 14:44:14 +02:00

4.1 KiB
Raw Blame History

Release Issue Template

Lotus X.Y.Z Release

What will be in the release

🚢 Estimated shipping date

<Date this release will ship on if everything goes to plan (week beginning...)>

🔦 Highlights

< See Changelog>

✅ Release Checklist

Note for whomever 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:

  • Fork a new branch (release/vX.Y.Z) from master 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 version.go in the master branch to vX.Y.(Z+1)-dev (bump from feature release) or vX.(Y+1).0-dev (bump from mandatory release)

Prepping an RC:

  • version string in build/version.go has been updated (in the release/vX.Y.Z branch).
  • 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

  • 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

  • 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)

  • Stage 4 - Stable Release

    • Final preparation
      • Verify that version string in version.go has been updated.
      • Ensure that CHANGELOG.md is up to date
      • Merge release-vX.Y.Z into the releases branch.
      • Tag this merge commit (on the releases branch) with vX.Y.Z
      • Cut the release here.

  • Post-Release

    • Merge the releases branch back into master, ignoring the changes to version.go (keep the -dev version from master). Do NOT delete the releases 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!