bjorn3 (Feb 04 2023 at 20:02): bjorn3 (Feb 04 2023 at 20:02):I'm curious how component versions will be handled. Will every component pin a single version for each dependency such that you can effectively use an SHA256 hash in the place of name+version? If so wouldn't that put a lot of burden on the whole ecosystem to release a new version every time a foundational component has a patch release with or without security fixes? And what if you need multiple components to use the exact same version of a dependency due to eg global mutable state (even if it is preferable to not have this, sometimes it is unavoidable. especially when porting existing systems to wasm)? How would you coordinate new releases in that case? Or will it be possible for the end user to use a newer patch version and minor version like semver? If so will it work with minimal versions like go, or with the latest version + lockfile for reproducibility? I just saw a lightning talk from 3 months ago where it is suggested but not explicitly voiced that the former strategy will be used. (It was talking among other things about how pushing an audit entry for one component indicating a security issue will cause audit to fail for all downstream components until they release a new version specifying the new version of their dependency that doesn't have a security fix)
Lann Martin (Feb 06 2023 at 14:05):A "development" (e.g. library) package will specify dependencies by version constraint(s). For reproducibility we'd like the dependency solver to itself be a versioned Wasm component and take as one of its inputs a snapshot of the registry state. After dependency solving you will be left with a "locked" component which would be appropriate for deployment.
Last updated: Nov 22 2024 at 16:03 UTC