search

vugu / vugu

Vugu: A modern UI library for Go+WebAssembly (experimental)
https://www.vugu.org
MIT License
4.8k stars 175 forks source link

Upgrade golang and tinygo #257

Closed Lord-Y closed 6 months ago

Lord-Y commented 6 months ago

Hello @bradleypeabody @owenwaller,

As said in the title, this PR will upgrade golang and tinygo. I let you guys make the review. For your local unit testing, go 1.21 and tinygo 0.30.0 will be needed.

Lord-Y commented 6 months ago

@owenwaller Any news about this one?

bradleypeabody commented 6 months ago

So on this one, do we really need to refactor and explicitly break compatibly with the older versions? ioutil.WriteFile is the exact same functionality as os.WriteFile, changing the method only serves to break older compatibility. I'm not entirely opposed but I just don't the benefit of making such changes.

powerman commented 6 months ago

So on this one, do we really need to refactor and explicitly break compatibly with the older versions? ioutil.WriteFile is the exact same functionality as os.WriteFile, changing the method only serves to break older compatibility. I'm not entirely opposed but I just don't the benefit of making such changes.

IMHO you just need to choose a policy: e.g. support last 2 Go versions or support as much Go versions as we can. This policy will answer all such questions. (To me last 2 versions sounds fine: to support more you'll need more developers power which you didn't have at the moment.)

bradleypeabody commented 6 months ago

Alright, fair enough. I'll go ahead and merge.

owenwaller commented 6 months ago

@powerman @bradleypeabody

Indeed, I have been thinking about this as well, but I wanted to get this merge in beforehand.

My general opinion is this we only support the Go versions the Go team support which is the last two. Using or building vugu outside of that is unsupported but might work. As there have been standard lib changes and functions that have been deprecated over time, we just have to accept the maintenance.

But I am thinking of making this stronger. Given that go 1.21 introduced the tool chain versioning changes in the go.mod I think we should only support versions >= go 1.21.

My rational for this goes like this. Go 1.22 is due circa Feb 2024. If the vugu v1 is after that date then we will support go v1.21 and go v1.22 which both have tool chain versioning support. If we ship before that we are supporting go 1.20 which doesn't have the tool chain versioning and go 1.21 which does.

If we don't have to make any changes to support go v1.20 then all is good. But if we do (and they are incompatible with go 1.21+) then I think we only support go 1.21+

I have had (other, closed source) project stuff recently which had a go 1.21.X style version string in a go.mod that barfed on an dev who was running go 1.20. So we may need to be careful. The fix was of course to upgrade go.

powerman commented 6 months ago

To me this sounds acceptable: we still support "last 2 versions", but in next couple months this may temporary mean "just 1.21" - if this will simplify anything. Just don't let this temporary decision to became permanent "last 1 version".

owenwaller commented 6 months ago

@powerman Yes, my suggestion to only support go v1.21.X for a strictly limited lifespan (i.e. until go v1.22 appears). I don't mean it to be mean or become only supporting only the latest version of Go.