Stop picking my Go version for me
blog.howardjohn.info
Stop picking my Go version for me
1–10 of 64 posts
Re: Stop picking my Go version for me
#2In other ecosystems, I could see how this could be a problem, but I don’t think I’ve ever had a problem with a Go upgrade.
What’re the actual, practical results of a package pushing you towards a higher go version that you wouldn’t otherwise have adopted right away? Why is this actually important to avoid beyond “don’t tell me what to do”?
Re: Stop picking my Go version for me
#3I always stay up with the latest go releases and if I am touching one of my packages that are set to lower in go.mod, I update it. It is an easy maintenance task to make sure I am keeping up with the latest standard library and tooling changes and improvements.
Re: Stop picking my Go version for me
#4In other ecosystems, I could see how this could be a problem, but I don’t think I’ve ever had a problem with a Go upgrade. What’re the actual, practical results of a package pushing you towards a higher go version that you wouldn’t otherwise have adopted right away? Why is this actually important to avoid beyond “don’t tell me what to do”?
One potential reason is that Go does drop support for older OSes sometimes. For example, Go 1.22 is the newest version that works with older Mac OSes.
Re: Stop picking my Go version for me
#5>It is not the version you use to compile your project
But it is the version which they support. Pushing it back to an older version may result in bad behavior even if it does compile.
Re: Stop picking my Go version for me
#6The author fails to mention any of the negative effects they experience due to this go version selection. They say that the effect is "viral" but don't give any concrete examples of why it's a bad thing to keep your toolchain up to date
Re: Stop picking my Go version for me
#7>My package really does depend on the latest patch release!
> Even in the event that your packages code is only correct with a specific patch release, I still think its wrong to put that version in the go directive unless it cannot be compiled with any other version.
I'm not a go user, but this strikes me as an over-reaction. If your code is only correct with a specific patch release, then it really is your business to make that so. If someone downstream wants to use library_method_broadly_correct and not library_method_correct_only_with_latest, then downstream should patch your source to allow them to do something unsupported. That becomes their problem. If this is likely to be a significant problem that will affect many users, then this is a codesmell warning you that you've probably got two libraries which you're just jumbling together into one: the solution isn't to falsely gate a safe function behind a high dependency version, nor to falsely release a function to people who can't use it safely, but to publish each with its own requirements expressly stated.
Re: Stop picking my Go version for me
#8The author fails to mention any of the negative effects they experience due to this go version selection. They say that the effect is "viral" but don't give any concrete examples of why it's a bad thing to keep your toolchain up to date
One of the key advantages of Go is its very compatible, you can compile and run early versioned code on the latest compiler without concern and it will just run with less bugs and faster due to all the advancements over time. I don't like being forced to upgrade my tooling until I choose the upgrade but in Go's case its usually trivial.
Re: Stop picking my Go version for me
#9The author fails to mention any of the negative effects they experience due to this go version selection. They say that the effect is "viral" but don't give any concrete examples of why it's a bad thing to keep your toolchain up to date
I am missing this part too. I can't really say ever having a problem upgrading go to the latest version. Now with "go fix", a lot of features are even improved automatically.
Re: Stop picking my Go version for me
#10>My package really does depend on the latest patch release! > Even in the event that your packages code is only correct with a specific patch release, I still think its wrong to put that version in the go directive unless it cannot be compiled with any other version. I'm not a go user, but this strikes me as an over-reaction. If your code is only correct with a specific patch release, then it really is your business…
Yeah, sounds like a skill issue.