Was there no RC this time? (Edit: I should get more sleep, betas come before rc). In any case, it's time indeed. I propose to separate generics support from the rest of 1.18, since this is a large feature that will require quite a bit of design and implementation effort.

Skimming through the draft release notes, I note the following:

• Fuzz support would be fancy, but realistically it is quite far out of GopherJS scope. I don't think we need to implement it.
• There is a number of new reflect methods, which we will have to support.
• Wrapper interface was removed from syscall/js.
• Some new mutex methods in the sync package.
• I think we'll get workspaces support for free, the same way we have modules support, but we'll have to verify that.

I've created a new go1.18-wip branch to do the work in.

Here's an easy recipe to start working on 1.18 support:

$ go install golang.org/dl/go1.18beta1@latest
$ go1.18beta1 download
$ go1.18beta1 install -tags gopherjsdev github.com/gopherjs/gopherjs &&  gopherjs test -v --short ./tests -p=1

My go1.18-wip branch now has complete Go 1.18 compatibility with the exception of generics, which brings us to the question of our approach to the release.

I plan to start working on generics at some point soon, but this is a large and complicated feature and will take a while to get right. The big question is whether to block GopherJS 1.18 release until that work is completed or not.

The main argument in favor of delaying the release is that generics is arguably the most important feature in Go 1.18 and it would be highly confusing to release GopherJS 1.18 without it; also generics seem like too big a feature to release in a patch-release of 1.18.x.

At the same time there are multiple arguments against postponing the release:

• A lot of important changes have been merged since our last stable release even not counting Go 1.18. Making them available to the general public would be nice.
• Go 1.19 will be released very soon. If we don't release a Go 1.18 compatibility release, GopherJS will no longer support any officially supported Go version, which is not great. According to our survey, most of our users use Go version that's no more than a year old, so it would cause inconvenience for some.
• Not everyone needs generics at this point, but many more people are interested in Go 1.18 compatibility in general.

When we discussed this with @flimzy a while ago we arrived at a middle ground of making several GopherJS 1.18beta releases until generics have landed, and then making a "stable" release. That way we can signal that we are not quite compatible with Go 1.18, and avoid releasing generics as a patch release.

I think we could go for that, but approach of Go 1.19 may be changing that equation a bit. We have to start on 1.19 support pretty much immediately after 1.18 is merged. We could release GopherJS 1.18 without generics and include them into GopherJS 1.19 release, which should happen soon-ish anyway.

I'm inviting the community to share their preferences, if any :)

I would prefer merging the go1.18 support without generics & then add generics later.

I'm not using Generics yet very much and I think anyone who is would catch the build failure right away.

I've merged the go1.18 branch to master today, and I am planning to tag a 1.18beta1 release once #1137 is merged. This change yields a noticeable file size reduction, which offsets small increases caused by Go 1.18.

GopherJS 1.18.0-beta1 is officially released. We plan to make a stable release once generics support is completed. If you are interested in Go 1.19 support, you can follow #1140.