Release planning for wasi-sdk 26.0 and 27.0

[sunfishcode]

We should do a release soon!

I think #527, changing the sysroot to be based on Lime1, makes sense. But it's likely that not all users will have engines that support that. And WebAssembly/wasi-libc#557 includes some important fixes that would benefit everyone.

So my thought is, to do a wasi-sdk 26.0 release then land #527, and then release 27.0. That way, if people update to 27.0 and hit problems, they'll at least be able to fall back to 26.0 without missing out on any of the fixes.

If anyone has concerns or questions, please reply here!

[yamt]

But it's likely that not all users will have engines that support that.

maybe ask feedback in the release notes explicitly so that we can reconsider it for future releases?

[lum1n0us]

Does it mean:

• By default, wasi-sdk will generate .wasm files as lime1 target, such as wasm32-wasip1 will actually be lime1, and wasm32-wasip1-thread will be based on lime1.
• There will be another set of targets using -mcpu=generic, like wasm32-generic-wasip1?

[yamt]

Does it mean:

* By default, wasi-sdk will generate .wasm files as lime1 target, such as `wasm32-wasip1` will actually be lime1, and `wasm32-wasip1-thread` will be based on lime1.

it changes how wasi-sdk's release libraries (libc.a etc) are built with.
it doesn't affect how application objects are built.
the final linked binary will basically have the union of them.

* There will be another set of targets using `-mcpu=generic`, like `wasm32-generic-wasip1`?

we currently use the same target triples, regardless of enabled wasm features. (well, except memory64)
i'm not aware of plans to change it for lime1.

[sparker-arm]

Is there a policy on when LLVM is updated in wasi-sdk? And would it make sense to align releases with LLVM..? I find it somewhat frustrating having to wait several months, maybe half a year, for wasi-sdk to play catch up. Maybe what I'd really like is to be able to always build wasi-sdk with a top-of-trunk of LLVM which, AFAICT, is not generally possible now.

[sunfishcode]

But it's likely that not all users will have engines that support that.

maybe ask feedback in the release notes explicitly so that we can reconsider it for future releases?

I'll document it in the release notes. And yes, we can reconsider it for future releases.

Does it mean:

* There will be another set of targets using `-mcpu=generic`, like `wasm32-generic-wasip1`?

As mentioned above, no, but this is the reason for doing two releases. Release 26 will use the current defaults, and release 27 will be the same but use the lime1-built libc.

Is there a policy on when LLVM is updated in wasi-sdk? And would it make sense to align releases with LLVM..? I find it somewhat frustrating having to wait several months, maybe half a year, for wasi-sdk to play catch up. Maybe what I'd really like is to be able to always build wasi-sdk with a top-of-trunk of LLVM which, AFAICT, is not generally possible now.

We've recently added a paragraph to the top of RELEASES.md saying it will be every three months.

[whitequark]

@sunfishcode I would really like to get #546 into a release if we manage to come to a consensus on what to do there quickly. Not being able to build complex C++ applications like LLVM/Clang or Slang has been the limiting factor on my use of the WASI SDK lately. I believe I'm far from alone in that.

[sunfishcode]

I was in the middle of running the release process when this issue came in. I can hold off on doing the final publish until we figure out what we want to do here.

[mh4ckt3mh4ckt1c4s]

36e12fd is tagged as wasi-sdk-26, but there is no corresponding release. This is a little confusing, if 36e12fd is not considered to be the 26 release could you please delete the corresponding tag?

[alexcrichton]

The release was paused to address #546

[mh4ckt3mh4ckt1c4s]

I understand that, but if #546 is to be merged before releasing wasi-sdk-26 then I guess the corresponding actual tag is incorrect?