Release Wasm 2.0.0

[rossberg]

Release package for Wasm 2.0 interpreter

[msprotz]

@rossberg: I was about to write you an email asking for an update when I saw you pushed this an hour ago! Seeing that this breaks pretty much any package using a previous version of wasm, do you mind submitting a change to kremlin/1.0.0/opam that changes >= "1.1.1" into = "1.1.1"? That'll prevent breakage of the opam repository.

@R1kM you are in charge of the kremlin opam package now, right? I pushed a branch wasm-2.0.0 that works with this update -- I'll merge it after this PR gets merged

[mseri]

Wait please, kremlin fails because he tarball has been modified:

#=== ERROR while fetching sources for kremlin.1.0.0 ===========================#
OpamSolution.Fetch_fail("https://github.com/FStarLang/kremlin/archive/refs/tags/v1.0.0.zip (Bad checksum, expected md5=b8bf9167faca0927f86cf5bb1d3d987a)")

[msprotz]

That's surprising. @R1kM did someone mutate the tag?

[rossberg]

@msprotz, is a change to Kremlin deps needed regardless?

FWIW, I don't understand much about Opam, but it seems dubious that it defaults to assuming compat even with future major versions – by definition, major version updates are expected to break stuff?

[msprotz]

I don't know what the semantics of OPAM's >= are with regards to major versions... @mseri can you tell us whether an update to kremlin is desirable, or whether I should just fix that in a followup PR on the repository?

[mseri]

FWIW, I don't understand much about Opam, but it seems dubious that it defaults to assuming compat even with future major versions – by definition, major version updates are expected to break stuff?

many packages don’t follow semver, and the module system makes it tricky to really follow it.

Opam itself just uses the metadata in the opam files to compute the set of compatible dependencies. When a release breaks old packages, we simply update the metadata alongside. It is not a problem and will maintain the opam repository stable, in this case, once the tarball for Kremlin is fixed, if there is a failure we will just update the upper bound in the relevant opam file in the opam repository

[mseri]

can you tell us whether an update to kremlin is desirable

If you mean updating the opam file in this repository, yes, that is what we normally do.

EDIT: of course, in addition to the opam file update, you are welcome to publish a new release of kremlin compatible with the updated dependencies

[rossberg]

if there is a failure we will just update the upper bound in the relevant opam file in the opam repository

Pardon my ignorance, but who is responsible for updating it, and doesn't a failure like this block the upstream update?

[mseri]

Us maintainers or who submits the PR. We usually help, but if you do it yourself alongside the PR this helps us dealing with it faster. In this case I would not make it block the PR since the package is not installable, instead I’d open an issue saying it is not installable due to modified tarball and move on (I am planning to do the tomorrow). Often we can recover the tarballs from some cache and fix it, but I cannot check before tomorrow

[mseri]

@msprotz @R1kM a cached version of kremlin zip is at http://opam.ocaml.org/cache/md5/b8/b8bf9167faca0927f86cf5bb1d3d987a can you please upload it on the github release? Otherwise I can add it to the backup opam source aechives and point at those some time tomorrow

[rossberg]

Okay, I removed the dune dependency, disabled the failing tests, and updated Kremlin's dependency. However, I assume the latter will generate loads of errors for now, as long as Kremlin is not installable. PTAL

[R1kM]

@msprotz To the best of my knowledge, nobody changed it, but maybe this was done with the recent project name change. I'll ask around.

@mseri If the tagged release was indeed changed, should we instead just update the hash on the ocaml-repository?

[mseri]

@mseri If the tagged release was indeed changed, should we instead just update the hash on the ocaml-repository?

Only if the content is unchanged. I am just about checking that. In any case, an uploaded artifact in the release is stable why github generated tarballs are not (they are re-generate every now and then and they can change if repository metadata changes)

[mseri]

I can confirm that they are unchanged, but since it is an autogenerated tag archive, which has proven to be unstable in the past, I have added the original zip to the opam-source-archive and pointed the sources to that one

[R1kM]

Thanks!

[mseri]

Thanks for the help and patience!