forest
forest copied to clipboard
Investigate the `types::build_version` module
Issue summary
The types::build_version
module contains a bunch of unusual code, like this:
https://github.com/ChainSafe/forest/blob/b9a5ff48ad8e708c53f5312d46736babea7d1c1b/types/src/build_version/mod.rs#L11
To be investigated:
- [x] What do the version numbers mean? Why are they different from
forest --version
? Are they required to mimic Lotus' api? - [x] What is
BuildType
/NodeType
? Was this part of Lotus? Can we remove it? - [x] Is there a reason to keep the module? If so, add the reason to the comments. If not, remove the module.
Other information and links
What do the version numbers mean? Why are they different from forest --version?
This build version is supposed to be the version of the binary (client, miner or worker) implementing the RPC-api.
In our case it's different from forest --version
.
Those numbers seem to come from a past release of Lotus (# 0.10.2 / 2020-10-14). Don't understand why it was choosen like this though. Let's use instead our forest build version and see what happens.
Are they required to mimic Lotus' api?
I don't think so, I think it's just for information purposes.
What is BuildType/NodeType? Was this part of Lotus? Can we remove it?
Those are similar of BuildType
/NodeType
in Lotus. NodeType
tracks the kind of binary that exposes the RPC-api:
binary | NodeType |
---|---|
lotus | api.NodeFull |
lotus-miner | api.NodeMiner |
lotus-worker | api.NodeWorker |
This is mainly used to determine the version of the RPC-api. I think we need to keep this.
For BuildType
, it's not really useful anymore (and it wasn't really correctly supported). This is mainly here to add information on which network the client is running (mainnet, calibnet, etc). Ie 1.17.1-dev+calibnet+git.5046b3165
.
We could refactor this code and use forest chain config settings.
Is there a reason to keep the module? If so, add the reason to the comments. If not, remove the module.
I think a little bit of clean up is needed, but overall this is a legit module to keep.
Also we shouldn't have two ways of computing forest version string.
Lotus uses build.UserVersion()
for both lotus -v
and initing its APIVersion.Version
string.
Excellent investigation. Could you create the PR for cleaning up the module?
Excellent investigation. Could you create the PR for cleaning up the module?
Sure.