search

helix-onchain / filecoin

Collection of libraries to implement common patterns and standards on the Filecoin Virtual Machine
Other
16 stars 14 forks source link

Release coordination with FM and built-in actors #203

Open anorth opened 1 year ago

anorth commented 1 year ago

This issue is an attempt to document a release process in coordination with the FVM and built-in actors. I expect this post to be updated in place with a process description as we converge on it in comments.

{Insert process here}

anorth commented 1 year ago

@Stebalien suggested a few things in Slack:

  1. When the builtin-actors enter "code freeze" for an upgrade, we need to: a. Create a release branch in https://github.com/helix-onchain/filecoin. b. Cut releases. c. Update the helix libraries in the builtin actors.
  2. More people need merge access (at the very least, aayush needs merge access).
  3. The builtin-actors should always be using the latest version of these libraries. Otherwise, breaking changes will accumulate.

(3) is interesting. From a simple POV, there should be no reason for built-in actors to upgrade these libraries if they don't want new functionality or APIs. Future new functionality may be actively unwanted, e.g. if we change the state schema (#188) to benefit most clients while the built-in actors don't want to perform the migration (yet). But an upgrade can be forced by the shared FVM libraries upon which both this and the built-in actors depend are upgraded, and the built-in actors want or are forced to take that upgrade. So there are two different things which can orthogonally prompt major version bumps, and clients might want one or the other (or both).

One possible approach to this would be to create release branches (and crate names) based on FVM version. Then each main FVM version line can have its own sequence of releases with associated changes. This would be quite a lot of overhead to maintain though.

The reverse possibility of release branches/crates based on functionality is also possible, but seems wrong.

A "simple" approach is for the built-in actors to just be ready to accept and integrate all API changes that come in these libraries (and if at some point they don't want them, fork). I think that's what (3) above is getting at, along with trying to front-load the integration work involved. But if we can find a way where built-in actors aren't forced to upgrade these libraries, that could be even better.

BigLep commented 2 weeks ago

(I'm working to get permissions to this repo so can do some issue cleanup/editing - slack thread)

Lets use this issue as the "Document the release process" issue.

We need to capture the steps taken and lessons learned as covered in https://filecoinproject.slack.com/archives/C029MT4PQB1/p1718328592682279 https://github.com/helix-onchain/filecoin/pull/232

I hope too once we document the steps, we can get some more automation going (maybe building off what is suggested in https://github.com/helix-onchain/filecoin/issues/181 ).