tetratelabs/wazero

wazero 1.0

codefromthecrypt opened this issue · 7 comments

codefromthecrypt commented

wazero 1.0 is an important milestone as it will be the first release, and we will do our best to not require an incompatible 2.0 immediately after ;)

To be able to deliver that promise, we have to define requirements vs "nice to have". This description will be revised as we close in on 1.0.

Requirements

  • JIT implementation for amd64 and arm64 arch, tested on Linux, MacOS and Windows
  • WebAssembly 1.0 (recommendation) spectests
  • WASI (wasi_snapshot_preview1) integration
  • Tested Examples
  • Benchmarks vs other runtimes
  • WebAssembly 2.0 (draft) compliance (#484)
  • Add Runtime.Close (#382)
  • wazero.io website
  • verify sandbox defaults. Ex. rng (#620)
  • Pass TinyGo and Zig tests in each compiler repository

Nice to have

Unlikely

  • DWARF debug support #58
  • WASI do over #263

Definitely not

codefromthecrypt commented

fyi watchers, I have requested to remove the text compiler for the 1.0 release tetratelabs/wabin#1

codefromthecrypt commented

#620 will also block 1.0

codefromthecrypt commented

TL;DR; Wazero 1.0 will have a floor Go version of 1.19, which means the 1.0 first cut will be in august 2022 and final cut in feb 2023. This aligns with current reality and gives a predictable plan to people as opposed to setting a sooner date and pushing to likely about the same anyway.

Overview

The overall plan is to cut a beta tag in 2 months (august) when Go 1.19 is released. Then, following Go's release schedule, when Go 1.20 is released (making 1.19 the last supported version), we release 1.0 final.

This gives us two more months to work out the majority of the API issues in wazero, and a 6 month period to adjust for commonly used, but not yet implemented backlog, and investigation around hard hitting things like component-model. This also gives us a better Go baseline which includes more programming tools including generics, memory model enhancements, atomics and godocs.

While no period is perfect and this seems a long time, it is better to have a plan and execute that vs bait and switch into the same sort of timeline, release 1.0 with known implementation concerns, or worse thrash 1.0 after promising it won't.

Wazero APIs are not stable

Based on recent experience, we've noticed that most users have run into an API affecting change every couple weeks or less. It would be a lie to suggest that we are at a stable release point, and it would also be foolish to stop changing the api just to say 1.0. While we have gone through quite a lot of improvements, we are still both stabilizing existing APIs and have an issue backlog on API enhancements. Some are quite tricky due to concurrency implications.

W3C APIs are not stable

Wazero 1.0 targets WebAssembly 2.0, which is only at draft 1. While true a subsequent draft could take years to publish, we should at least be more aware of the bugs in the current draft after some months of experience and watching the spec repo.

Some feature requests need more time and tooling

We've had feature requests that have more concurrency concerns than before. For example, reloading a function into a running module. Using features like atomics in Go 1.19, as well promises made with the memory model will allow safer internals, which make some features that aren't affordable now, more affordable. Go 1.19 is not far away and already in beta. More on that below.

Go 1.19 is the correct floor version

We have been battling with things improved in Go 1.19 since this project started, including unsafe pointers, godoc and vagueries in the memory model. Some features we implement are not implemented safely (ex globals are not atomic). Moroever, implementing things safely in a way that works both in JIT code and host functions requires a stable understanding of the memory model, which was changed in Go 1.19.

Go release cadence matches a likely outcome anyway

Based on our Go support policy, we can't use 1.18 features until 1.19 is out. Knowing we will eventually target 1.19, means we can't release until 1.20 is out. However, this doesn't mean we can't begin work on 1.19 until 1.20. All this means is we have to create branch for users that can continue to work on 1.18 until that's no longer the floor version.

Whie likely for Go 1.18, it is unlikely we'll need to expose any new Go APIs from 1.19 into wazero's public API. This means many users can ignore Go 1.19 and think more about Go 1.18, except when thinking about having to eventually move to 1.19 when 1.18 is no longer supported by Go.

Release plan

In august, we'll create a long term branch 1.0beta and initial tag 1.0beta1 with has a floor go version of 1.18. This gets tagged monthly with critical bug fixes and any public API changes monthly until 1.0 final is released next year.

When go1.20beta1 is out (likely Dec or Jan), we start making tags on main prefixed 1.0rcN at the same time as we release beta tags. After Go 1.20 is released, we release 1.0 off main and stop releasing beta and rc tags.

Release schedule

While Go has slipped schedule before, and it takes a few days for CI to update versions, so this targets the end of each month.

  • 2022-08-31 - 1.0beta1 First versioned API with floor Go version 1.18
  • 2022-09-30 - 1.0beta2 API changes and bug fixes
  • 2022-10-31 - 1.0beta3 API changes and bug fixes
  • 2022-11-30 - 1.0beta4 API changes and bug fixes
  • 2022-12-30 - Final API
    • 1.0beta5 - floor Go version 1.18
    • 1.0rc1 - floor Go version 1.19
  • 2023-01-31
    • 1.0beta6 - floor Go version 1.18 bug fixes
    • 1.0rc2 - floor Go version 1.19 bug fixes
  • 2023-02-28 - 1.0 floor Go version 1.19 final cut. No more beta (1.18) releases.
codefromthecrypt commented

One thing I forgot to document is the rationale of doing planned betas vs other norms.

  • Cut 1.0 for emotional or marketing reasons and break it anyway
    • Emotionally satisfying for maintainers, but harms the integrity of the project.
  • Cut 0.x versions forever
    • Emotionally satisfying for maintainers, possibly with some planning for users.
    • However, no semantics or promises about API compat
  • Don't cut anything until 1.0 and skip the beta
    • This is what we are doing today, but it lacks a coherent ability to communicate change between commits
    • This also doesn't help anyone with planning

For people who are used to 0.x forever thing, basically you can translate 1.0beta1, 2 etc to 0.1 0.2 just we have some promises we are making in schedule, baseline go versions and the idea that it will eventually and in a fixed timeframe reach 1.0!

codefromthecrypt commented

To adhere to go's tagging recommendations, the first beta tag is v1.0.0-beta.1 https://go.dev/doc/modules/version-numbers

mathetake commented

I believe this 1.0 should pass all the Zig and TinyGo integration tests

  • 👍2
codefromthecrypt commented

#1032 slips this to march as we have already identified a lot of gaps while adding FS integration tests