> In "The pre-release suffix indicates a version is a pre-release. Pre-release versions sort before the corresponding release versions. For example, v1.2.3-pre comes before v1.2.3.", Why do they mention the sorting part? Whats the relevance?
Claude said:
> Good question! It's because Go's version resolution relies heavily on sorting/ordering to decide which version to pick. For example when you do go get golang.org/x/tools@latest — what's "latest"? Go needs to sort all available versions and pick the highest one. If pre-releases sorted after release versions, then v1.2.3-pre could be considered "newer" than v1.2.3, and @latest might accidentally give you a pre-release when you didn't want one. By explicitly saying pre-releases sort before their release counterpart, Go guarantees that:
@latest won't accidentally resolve to a pre-release v1.2.3 is always considered "higher" than v1.2.3-pre Version ranges and minimum version selection behave predictably
It's basically setting expectations — "don't assume pre-releases are newer just because they have extra stuff in the version string."
---
I wasnt' sure so then I asked:
> is that how go get works really or?
Claude:
> Honestly, I oversimplified it a bit! @latest in Go specifically means the latest tagged release version — it explicitly excludes pre-releases by definition, not just because of sorting. The sorting relevance is more about Minimum Version Selection (MVS) — Go's algorithm for resolving dependencies. When multiple modules in your dependency graph require different versions of the same module, Go picks the minimum version that satisfies everyone. For that algorithm to work correctly, versions need a well-defined order. So the sorting mention is more about making sure the ordering is unambiguous and predictable for MVS, rather than specifically about @latest behavior. I shouldn't have used that as the example
Happens every single time. A bit tiring
No comments yet.
