I’ve come up with a set of rules for developers to make the updates process smooth. It’s tightly tied to this comment, because it also touches testing, but it also slightly expands this design.
ffnet.wasm, which contains the current runtime published to the ffnet. It can be either stored in the repository or provided with a script fetching if from a commit containing the last release, but this could affect developers’ experience. We also introduce
previous_spec.wasm, which contains the last implementation of the previous runtime spec. It probably can’t be easily fetched dynamically, so it must be stored in the repository.
The node always runs the WASM runtime to make its behavior more predictable no matter which network it’s running on. The only exception is local
dev, which always uses native.
Every change to the runtime must result in update of
latest.wasm. If there’s a specification change, it must be additionally preceded with copying
previous_spec.wasm. All spec changes between two ffnet releases should be clustered into a single version bump and
The CI runs e2e tests three times: once with
latest.wasm, once with
previous_spec.wasm and once with
ffnet.wasm. This ensures that
master always can be published to replace the current ffnet after either implementation change (compatible with the previous spec and the current ffnet) and specification change (compatible with the current ffnet) in the runtime.
Some old e2e tests are guaranteed to fail with the new runtime and some new tests will fail with the old runtime due to breaking changes. To cope with that some tests need to start with a runtime version check. If it’s one known to be incompatible, the test should terminate immediately with a success.
The devnet is updated whenever there’s a merge to
master. The CI artifacts of the node and the CLI are considered canonical on the devnet. If there’s a change in the runtime, it must be published on the network immediately. This may cause need to quickly update the node and the clients, but that’s to be expected on the devnet and shouldn’t slow down development.
The ffnet is updated manually. The update must be marked with a git tag and a GitHub release.
latest.wasm must be copied to
ffnet.wasm, if it’s decided to be stored in the repository.
If there’s only an implementation change in the runtime since last published version, it can be published on the network immediately. Otherwise the change must be announced to the community to give it time to upgrade and only after at least a week it can be published on the network.