Nana-EC
commented
6 days ago @david-bakin-sl checking but is this not captured by the contents of https://github.com/hashgraph/hedera-smart-contracts/tree/main/contracts-abi/contracts/system-contracts What's an example of a consensus node API that isn't the user API? Agreed and the intent should be each change on CN prompts a version bump in this repo with a note of the CN version also
At any given time the
contracts/system-contractsdirectory holds the current definitions of system contracts - methods and structs. And that works for most developer who want to compile contracts that run on the current network.But those things get versioned over time. And there are some use cases where it is needed to specifically refer to older versions as well as the current version. Most obvious one is in testing, esp. test frameworks, where a test setup for someone might need to test that it works with older as well as the current version of APIs.
Suggestion: Add to the smart contract repo a directory for "consensus node API" distinct from "current user API" (the latter being what we have). It would simply contain a directory for each distinct historical API - i.e., every time we modify an existing systme contract or add a new one we'd add a new version directory. Naming convention here TBD - could be dates, could be arbitrary v1 v2 v3 ... (completely independent of the repo's own release number).
(Another use case this would support would be being able to use the smart contract repo as ground truth in the smart contract service of the consensus node (and mirror node). I.e., being able to generate code from it. That use case needs all historically supported versions.)