You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The version policy we agreed on in #358 bumps the major version of ref-fvm whenever ref-fvm changes are needed to accompany a new network version. This means that clients will need to depend and select across several ref-fvm versions to (a) ride network upgrades, and to (b) provide historical chain support. We should make it easy for client implementations to select the right ref-fvm version based on network epochs/NVs.
Proposal
Build a separate crate fvm-selector within this repo that acts a selector and provides a standard, unified interface that can be shimmed to support multiple backing Engines, MachineContexts, Machines, Executors, etc.
More definition needed.
The text was updated successfully, but these errors were encountered:
This has been implemented in the FFI itself. We may still want something in this repo (for other users) but it's no longer a release blocker (so I've removed it from the roadmap).
Context
The version policy we agreed on in #358 bumps the major version of ref-fvm whenever ref-fvm changes are needed to accompany a new network version. This means that clients will need to depend and select across several ref-fvm versions to (a) ride network upgrades, and to (b) provide historical chain support. We should make it easy for client implementations to select the right ref-fvm version based on network epochs/NVs.
Proposal
Build a separate crate
fvm-selector
within this repo that acts a selector and provides a standard, unified interface that can be shimmed to support multiple backing Engines, MachineContexts, Machines, Executors, etc.More definition needed.
The text was updated successfully, but these errors were encountered: