v0.45.3 doesn't build with go 1.15

[crodriguezvega]

Summary of Bug

The go.mod of v0.45.3 requires go version equal or above 1.15, but building with go 1.15 fails with error:

# github.com/cosmos/cosmos-sdk/x/upgrade/keeper
x/upgrade/keeper/keeper.go:380:9: undefined: "os".WriteFile

It looks like this PR changed ioutil.WriteFile to os.WriteFile, but os.WriteFile was only introduced in go 1.16. The CI that run for that PR used go 1.16, so I guess that's why this went unnoticed.

This problem was found while trying to bump the SDK version in the v1.4.x and v2.2.x release lines of ibc-go (both of them require go version equal or above 1.15)

Version

0.45.3

Steps to Reproduce

• Check out 0.45.3.
• Make sure go version is 1.15.
• make build.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

Interesting. I would think go.mod would catch this somehow? But I guess not. In any case, there's no reason whatsoever to use go 1.15, so just update your go version to 1.17 or 1.18.

We can update v0.45.x to state go 1.17 as a min version. This is what I'd do. Thoughts @AmauryM or @marbar3778 ?

[amaury1093]

We can update v0.45.x to state go 1.17 as a min version.

SGTM.

[tac0turtle]

SGTM

[crodriguezvega]

Sorry, but wouldn't it be easier to just revert this change and put back ioutil.WriteFile? That way you can keep go 1.15 in go.mod, and then ibc-go doesn't need to change its minimum required go version. We are facing this problem in existing release branches (v1.4.x and v2.2.x), so we cannot change the minimum required go version, because that's for us an API breaking change requiring a major version bump.

[alexanderbez]

It's preferable to keep up to date with the latest Go versions. Why would bumping the min Go version require a breaking API change? Unless you're relying on a Go API that broke, e.g. ioutil, then it's not breaking.

[crodriguezvega]

Because in patch or minor releases our promise with developers/integrators is that they can just swap the version of ibc-go they have without having to change any of their code or environment setup. So if we have, e.g. v1.4.0 with minimum required go version 1.15, and then we release 1.4.1 (with the next SDK 0.45.x) with minimum required go version 1.17, we would be breaking our promise.

[alexanderbez]

But changing the environment is an OK thing to do. The code will operate as expected w/o breaking APIs, which is what semver is about. I'm personally against sticking with 1.15

[crodriguezvega]

Closed by #11686.