Conversation
The dialect used since 0.37 has been continued as 1.0. The endpoints should have the "/v1" prefix in 1.0, but the current API does not facilitate adding this to the request URL path automatically. The CometBFT Go client API does not do that either, so there is consistency.
Also added notes on RPC versioning to the documentation of client APIs.
|
Given that the RPC data format changed in v0.37, it feels a bit weird to me to name the corresponding combat mode I fear it might be confusing for users when they have to specify a compat mode for a node running CometBFT 0.37, as I suspect they would intuitively want to specify I would suggest two things: I am partial to option (a) as it seems the cleaner to me, as it expresses exactly the boundaries at which backward incompatible changes were made to the RPC data format, but I could see a case for (b) in case we want to account for the |
|
I agree @romac, there is no need for the third variant and the "starting from" semantics are less confusing. |
Last thing to do for cometbft/cometbft#1834
The dialect used since 0.37 has been continued as 1.0.
The endpoints should have the
/v1path prefix in 1.0, but the current API does not lend itself to adding this to the request URL path automatically. Update the docs to mention the need to explicitly encode the version path in the URL used by the client.The CometBFT Go client API does not do that either, so there will be consistency at least.
.changelog/