wazero 1.0 #506
Comments
|
fyi watchers, I have requested to remove the text compiler for the 1.0 release tetratelabs/wabin#1 |
|
#620 will also block 1.0 |
|
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. OverviewThe 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 stableBased 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 stableWazero 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 toolingWe'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 versionWe 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 anywayBased 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 planIn 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 scheduleWhile Go has slipped schedule before, and it takes a few days for CI to update versions, so this targets the end of each month.
|
|
One thing I forgot to document is the rationale of doing planned betas vs other norms.
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! |
Note: I can refactor this further with clarification of scope on the wasm loaded. It could be a lot faster. Also, if there's a way to name the module per request, that's better (ex a request ID or a UUID of some kind) especially for logging. I simplified the logging also as the high-level issue is out of memory when there's an out of range read or write. I can modify or revert that if you like. FYI wazero's first beta tag will be in one month tetratelabs/wazero#506 (comment) Signed-off-by: Adrian Cole <adrian@tetrate.io>
Note: I can refactor this further with clarification of scope on the wasm loaded. It could be a lot faster. Also, if there's a way to name the module per request, that's better (ex a request ID or a UUID of some kind) especially for logging. I simplified the logging also as the high-level issue is out of memory when there's an out of range read or write. I can modify or revert that if you like. FYI wazero's first beta tag will be in one month tetratelabs/wazero#506 (comment) Signed-off-by: Adrian Cole <adrian@tetrate.io>
|
To adhere to go's tagging recommendations, the first beta tag is |
|
I believe this 1.0 should pass all the Zig and TinyGo integration tests |
|
#1032 slips this to march as we have already identified a lot of gaps while adding FS integration tests |
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
Nice to have
Unlikely
Definitely not
The text was updated successfully, but these errors were encountered: