Create updated release process
BigLep opened this issue · 2 comments
BigLep commented
Done Criteria
There is a clear set of documented steps that a "release engineer" can follow for cutting.
Outdated documents (example maybe) are updated or removed.
Why Important
Release processes as tribal knowledge have the problem of:
- Doesn't survive if tribe members leave or are away. Others "groping around" may make mistakes which takes more time later.
- Less likely that lessons learned or improvements will be captured and passed on.
User/Customer
Maintainers
Notes
- During the nv23 release process, it seemed that we didn't have the list of steps needed for cutting a release, especially when older versions also needed to be updated. See comment in #2013 (comment) .
- There are steps around fvm_integration_tests. See #2013 (comment) and https://filecoinproject.slack.com/archives/C029MT4PQB1/p1718240205547329
- There is currently this document form a couple of years ago: https://github.com/filecoin-project/ref-fvm/blob/master/doc/testnet-release-process.md that should be updated or removed.
Stebalien commented
- The
fvm_integration_tests
issue would be solved by automatically publishing releases to crates.io whenever the version gets bumped. - We definitely need some CI for a dry-run (#2004) publish to catch issues.
- We need documentation for updating proofs and wasmtime. We usually don't release v2 & v3, but I try to do so whenever I update the proofs library and/or wasmtime to reduce code bloat due to duplicate crates.
rjan90 commented
- We should remove the outdated document, and rather move/create a doc on "how to update ref-fvm dependency in Lotus"