I used to see supporting multiple versions of Python as an expensive chore... and then I learned how to use the GitHub Actions matrix feature and supporting multiple versions is suddenly easy - my test suites are comprehensive enough that if they pass I'm confident it will work on that version. I expect this should work equally well for Go.
Stop picking my Go version for me
61–64 of 64 posts
Re: Stop picking my Go version for me
#62The transitive dependency case is what makes this painful in practice. You’re not even choosing that library it’s three levels deep in your dependency tree, and suddenly CI fails because some maintainer ran `go get go@latest` on a Saturday.
That's not how that works in the Go ecosystem: you don't get that dependency upgrade unless you explicitly upgrade the dependencies of your project. The Go toolchain uses the "Minimum Version Selection" algorithm.
Re: Stop picking my Go version for me
#63Unless I am mistaken or had some other fluke it will also just happily download the old version and build with that, even if there was a vulnerability, which has mostly led me to always bumping to the latest release when I touch it. Someone n another thread mentioned the `toolchain` command, maybe I should look into this again.
Re: Stop picking my Go version for me
#64Earlier quoted context omitted.
Are you sure you replied to the right comment? I'm not sure how this relates to the question being asked.
I did. If you have an older tool chain, it is on you to fix the library to build with the older tool chain, that's what open source is about!
Sorry, I have no idea what you're talking about. Please double check the message thread to which you're replying.