3 ms·

go modules was enabled by default in Go 1.16

chrismorgan 6y ago
The impression I’m getting is that Go modules have version numbers, but that the version number is basically just a sort of string where the only available option is comparing version numbers, so that there’s no resolution algorithm (e.g. “>1.16, <2”), and consequently no potential for version maintenance (which would be why major versions have to have a new URL). Semantically, then, this is no different from version numbers being just integers. Is this correct?
- morelisp 6y ago
  This is not quite correct. Go understands `-u=patch` vs. `-u` to refer to patch vs. minor version. It also forces you to use a different path for each major version, by parsing the major version (and conversely also ignores version tags less than the path version so you can't get a "v2" path with "v1.1.3"). So it simultaneously understands semver in the "porcelain" tools, but version resolution per se is really only bounded on the low side because any upgrade preserving the path should be safe.
  - Groxx 6y ago
    It's not "minor" though, `-u` just means "update it". If that happens to be v1.1.0 to v200.3.4, it'll just make that change. The reason it's often claimed to be minor is: modules at v2 or beyond should have a different import path than v1, so they're actually a 100% different library with no implied relation to the v1 version (there may be one, but none is implied). So v2.x -> v3 will never auto-update - that'd be crazy, they're different libraries. You can even have them both installed at the same time, at different versions, node_modules-like, just like any other two different libraries. I say "should" because it's not enforced - if you ignore this and just tag a v200.3.4 with no v2...v200 folders or other providing modules, it'll be marked as v200.3.4+incompatible, and -u will plow through every other major semver version blindly. Because it doesn't understand semver, it just has imports and can sort strings.
    - morelisp 6y ago
      I mean the `+incompatible` gets added there for a reason, it's not doing it "blindly" because it "doesn't understand" it. You might not like what what go tooling does with its semver awareness, but it is semver-aware.
      - deleted 6y ago
        [deleted]
      - deleted 6y ago
        [deleted]
      - Groxx 6y ago
        It's not incompatible with semver though, it's just incompatible with Go's "semver is folders". Go's "semver" is full of weird corners. E.g. if you tag v1.2.3 and then someone does a `go get ...@master`, they get "version" `v1.2.4-timestamp-gitsha`. `v1.2.4` doesn't exist anywhere, Go just makes it up: https://golang.org/ref/mod#pseudo-versions https://golang.org/ref/mod#pseudo-versions . It works for their system with minimal changes, and is thus a clever hack, but it's definitely weird.

The impression I’m getting is that Go modules have version numbers, but that the version number is basically just a sort of string where the only available option is comparing version numbers, so that there’s no resolution algorithm (e.g. “>1.16, <2”), and consequently no potential for version maintenance (which would be why major versions have to have a new URL). Semantically, then, this is no different from version numbers being just integers. Is this correct?

morelisp 6y ago
This is not quite correct. Go understands `-u=patch` vs. `-u` to refer to patch vs. minor version. It also forces you to use a different path for each major version, by parsing the major version (and conversely also ignores version tags less than the path version so you can't get a "v2" path with "v1.1.3"). So it simultaneously understands semver in the "porcelain" tools, but version resolution per se is really only bounded on the low side because any upgrade preserving the path should be safe.
- Groxx 6y ago
  It's not "minor" though, `-u` just means "update it". If that happens to be v1.1.0 to v200.3.4, it'll just make that change. The reason it's often claimed to be minor is: modules at v2 or beyond should have a different import path than v1, so they're actually a 100% different library with no implied relation to the v1 version (there may be one, but none is implied). So v2.x -> v3 will never auto-update - that'd be crazy, they're different libraries. You can even have them both installed at the same time, at different versions, node_modules-like, just like any other two different libraries. I say "should" because it's not enforced - if you ignore this and just tag a v200.3.4 with no v2...v200 folders or other providing modules, it'll be marked as v200.3.4+incompatible, and -u will plow through every other major semver version blindly. Because it doesn't understand semver, it just has imports and can sort strings.
  - morelisp 6y ago
    I mean the `+incompatible` gets added there for a reason, it's not doing it "blindly" because it "doesn't understand" it. You might not like what what go tooling does with its semver awareness, but it is semver-aware.
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - Groxx 6y ago
      It's not incompatible with semver though, it's just incompatible with Go's "semver is folders". Go's "semver" is full of weird corners. E.g. if you tag v1.2.3 and then someone does a `go get ...@master`, they get "version" `v1.2.4-timestamp-gitsha`. `v1.2.4` doesn't exist anywhere, Go just makes it up: https://golang.org/ref/mod#pseudo-versions https://golang.org/ref/mod#pseudo-versions . It works for their system with minimal changes, and is thus a clever hack, but it's definitely weird.