Bump module serialization format to v2 #1223
Conversation
| /// Version for cosmwasm_vm 1.0.0-beta5 / wasmvm 1.0.0-beta6 that ships with Wasmer 2.1.1. | ||
| /// - **v3**:<br> | ||
| /// Version for Wasmer 2.2.0 which contains a [module breaking change to 2.1.x](https://github.com/wasmerio/wasmer/pull/2747). | ||
| const MODULE_SERIALIZATION_VERSION: &str = "v2"; |
There was a problem hiding this comment.
Can't this be derived or imported from wasmer somehow? That will make this code support all versions transparently (new test below would have to me modified).
There was a problem hiding this comment.
No, the version is not exposed yet. This might change in the future. They added a versioning schema in wasmerio/wasmer#2747. However, it is not exported. So currently they just say it can change at any time.
If we get the version, we can check much better that we don't miss an update. However, we might want to keep control over the version number since it can include our own format changes as well. E.g. we could rename the file names from <checksum> to <checksum>.module or compress the modules before writing them to disk.
There was a problem hiding this comment.
If we get the version, we can check much better that we don't miss an update. However, we might want to keep control over the version number since it can include our own format changes as well. E.g. we could rename the file names from
<checksum>to<checksum>.moduleor compress the modules before writing them to disk.
When wasmer module format version is published, we can consider that plus our own version number, either in a subdir or with a minor / patch format, i.e. {}/{} or {}.{} / {}-{}.
There was a problem hiding this comment.
In 9f5716c you see an approach that hacks into the private header information. This way we ensure a module version change is noticed.
We could hash the full Wasmer module header into the file path, like format!("v3-wasmer{}", &header_hash[0..8]). Then the bumping happens automatically.
The only issue I see with this approach is that it is not obvious for admins which cache directory is used and which one is obsolete.
There was a problem hiding this comment.
We could hash the full Wasmer module header into the file path, like
format!("v3-wasmer{}", &header_hash[0..8]). Then the bumping happens automatically.
I like it. At least, until there's a public wasmer module format version number.
The only issue I see with this approach is that it is not obvious for admins which cache directory is used and which one is obsolete.
Not a big issue. The one being used will always contain more recent files, and those can be easily detected
There was a problem hiding this comment.
Good stuff. Let's continue the conversation in #1224 as Wasmer 2.2.0 will be the first version in which the relevant information is stored in the module headers.
No description provided.