search

filecoin-project / ref-fvm

Reference implementation of the Filecoin Virtual Machine
https://fvm.filecoin.io/
Other
385 stars 140 forks source link

Create updated release process #2018

Closed BigLep closed 3 months ago

BigLep commented 5 months ago

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:

  1. Doesn't survive if tribe members leave or are away. Others "groping around" may make mistakes which takes more time later.
  2. Less likely that lessons learned or improvements will be captured and passed on.

User/Customer

Maintainers

Notes

  1. 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 https://github.com/filecoin-project/ref-fvm/issues/2013#issuecomment-2163858925 .
  2. There are steps around fvm_integration_tests. See https://github.com/filecoin-project/ref-fvm/issues/2013#issuecomment-2166834018 and https://filecoinproject.slack.com/archives/C029MT4PQB1/p1718240205547329
  3. 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 5 months ago
  1. The fvm_integration_tests issue would be solved by automatically publishing releases to crates.io whenever the version gets bumped.
  2. We definitely need some CI for a dry-run (#2004) publish to catch issues.
  3. 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 5 months ago