Type discrepancy in DeploymentInfo between codebase and rpc/README.md documentation

[eval-exec]

The type of threshold in DeploymentInfo is defined as Ratio in the codebase

ckb/util/jsonrpc-types/src/info.rs

Lines 47 to 73 in 287bc09

	pub struct DeploymentInfo {
	/// determines which bit in the `version` field of the block is to be used to signal the softfork lock-in and activation.
	/// It is chosen from the set {0,1,2,...,28}.
	pub bit: u8,
	/// specifies the first epoch in which the bit gains meaning.
	pub start: EpochNumber,
	/// specifies an epoch at which the miner signaling ends.
	/// Once this epoch has been reached,
	/// if the softfork has not yet locked_in (excluding this epoch block's bit state),
	/// the deployment is considered failed on all descendants of the block.
	pub timeout: EpochNumber,
	/// specifies the epoch at which the softfork is allowed to become active.
	pub min_activation_epoch: EpochNumber,
	/// the length in epochs of the signalling period
	pub period: EpochNumber,
	/// the ratio of blocks with the version bit set required to activate the feature
	pub threshold: Ratio,
	/// The first epoch which the current state applies
	pub since: EpochNumber,
	/// With each epoch and softfork, we associate a deployment state. The possible states are:
	/// * `DEFINED` is the first state that each softfork starts. The blocks of 0 epoch is by definition in this state for each deployment.
	/// * `STARTED` for all blocks reach or past the start_epoch.
	/// * `LOCKED_IN` for one period after the first period with STARTED blocks of which at least threshold has the associated bit set in version.
	/// * `ACTIVE` for all blocks after the LOCKED_IN period.
	/// * `FAILED` for all blocks after the timeout_epoch, if LOCKED_IN was not reached.
	pub state: DeploymentState,
	}

.

However, in the rpc/README.md DeploymentInfo file, it is documented as being of type EpochNumber, and the since field is not yet documented for DeploymentInfo.

It appears that there may be an issue with the ./devtools/doc/rpc.py file.

[eval-exec]

In this PR , I generate right rpc doc, but it didn't pass the CI job. Also, there appears to be an issue with the CI action.

[chenyukang]

The line of 110 could be removed?

https://github.com/nervosnetwork/ckb/blob/develop/Makefile#L110-L111

[chenyukang]

Seems there is an issue in cargo doc, note the ratio part:

Use cargo +nightly doc to generate the doc html is OK.

[eval-exec]

I think we can use cargo doc --workspace to generate all workspace members, this will generate right cargo doc.

[chenyukang]

cargo +nightly will change the format of HTML documents, which introduces a lot of differences rpc/README.md, there is some existing code to handle this kind of issue:

ckb/devtools/doc/rpc.py

Line 291 in 0c4565b

# after 1.56 rustdoc change relative link

HTML is prone to change, we'd better use another solution to generate rpc/README.md in the future.

A possible solution is to use rustdoc to generate json format, such as:

cargo +nightly rustdoc  -p ckb-fixed-hash  -- -Z unstable-options --output-format json

Out of curiosity, why do we generate rpc/README.md?

[eval-exec]

why do we generate rpc/README.md?

Cc. @zhangsoledad

I think we can view RPC modules to learn what APIs we have.

[doitian]

Out of curiosity, why do we generate rpc/README.md?

Make document close to the code.