-
Notifications
You must be signed in to change notification settings - Fork 451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encode metadata version in the metadata itself? #941
Comments
An argument against using So for the sake of maintainability keeping both |
So do you think the aforementioned approach of an enum (same as
or having a version field:
Also the question of backwards compatibility for the existing format which doesn't include the version number. We could add a special prefix to specify that this is now the "versioned" metadata. |
Discussed this with @ascjones over PM. Basically on Substrate metadata we had the same thing - V0 was not an enum, then from V1 onwards it was. So we can actually use that info and the lack of the same fields inside the new to detect, so basically... This is V0, check for existence of metadataVersion to detect this path -
This is V1, if we cannot find the above detection field, we parse it as an enum.
So basically - if we find |
@ascjones I think we can close this issue? |
I believe so, we have the versioning enum implemented. |
In use-ink/cargo-contract#347 I am extracting the version of the
ink_metadata
crate to specify the version of the metadata.This assumes that metadata version ==
ink_metadata
crate version, which would be a safe assumption if we are following semver for wire-format compatibility.However, at the moment we are just bumping
ink_metadata
along with the otherink!
crates. If that will be our policy moving forwards, then we will need to encode the version in the metadata itself, instead of using the crate version.We could do that using an enum e.g.
enum Metadata { V1(Vec<u8>), V2(V2Metadata) }
like withframe_metadata
, which allows supporting multiple metadata versions. Or we can just add aversion
field to the contract metadata struct and populate it with a constant value.It would be good to provide some mapping of crate versions to metadata versions, possibly in the
README
e.g.The text was updated successfully, but these errors were encountered: