7 ms·

Actually, Go used a very elegant solution to a hard problem of modularization: directories. A directory == a package. Import path specifies a path to the direct

Actually, Go used a very elegant solution to a hard problem of modularization: directories. A directory == a package. Import path specifies a path to the directory that contains a package. A package may, or may not, decide to have a stable API and document it. If it does, and it commits to the version 1.0, then it basically gives a promise: "This package will not change its API in a way that will break correctness of currently-correct programs that use it". Since a package == a directory, if you want to keep package compatibility, you must not change the contents of the import directory. Therefore, you need to create a new one, preferably called v2/, to put the new code in.

tkiolp4 5y ago
It’s an elegant solution for packages that don’t use versioning features like git tags. For every other package out there that uses git tags, it’s just a lazy solution: why on earth would I want to specify the version in the path? Git tags solves that problem in a more elegant way (both from the side of the maintainers and users).
- paskozdilar 5y ago
  > it’s just a lazy solution: why on earth would I want to specify the version in the path? It's not a lazy solution, just opinionated. Personally, I love the fact that just by seeing the import path I know exactly which codebase is used. I don't have to open my go.mod, see which version I'm using, clone the repository, dig through the history to check out a specific tag and see what code is actually used in my program... I just open the repo in my browser and browse through the directories. There isn't a single system on earth that doesn't support directories! I also love the fact that I don't have to know s**t about git to use Go. If Go was to suddenly switch to git tags, not only would it break a massive amounts of existing code, but would basically force everyone to learn about git tags just to be able to see what code are they using, which would raise the amount of paperwork I have to fill in order to work on the thing I care about. Go is fundamentally against needless paperwork.
  - Dylan16807 5y ago
    > I just open the repo in my browser and browse through the directories. Browse via what? It would be entirely reasonable, not weird at all, if git.example/user/repo/ showed a list of branches and tags. And then it would actually be easier to reach git.example/user/repo/v3/ than to reach git.example/user/repo/master/v3/ The particular way github does directories isn't canonical. And if you wanted to clone the repo, you could clone a specific branch easily. When it comes to minor versions, you have to dig anyway to see the matching source under the current system.
    - paskozdilar 5y ago
      > Browse via what? Via whatever tool you have available. Most projects also have a download link or a clone command written, in case the remote repo doesn't support in-browser file listing, so you can download it and browse locally, without needing to checkout tag or whatever. > if you wanted to clone the repo, you could clone a specific branch easily. Unless I don't know how to clone a specific branch - in which case I need to learn about git branches, figure out how they work, and how to clone a specific branch, and how to go back to master etc. etc. etc. In contrast to just cloning the repo and browsing the v2/ directory.
      - Dylan16807 5y ago
        You blew past my main point, which is that if you go to browse an entire repo online, there's no reason that a v2/ directory will be easier to find than a v2/ branch, unless you're specifically assuming the site looks like github. > In contrast to just cloning the repo and browsing the v2/ directory. "just" cloning the repo? You gave this list of arduous steps for why cloning a tag is harder than browsing, but "just" cloning the repo still makes you do all but one of those steps! And if something is generating the clone command for you, it can add "-b". You don't need to know how git branches work. You definitely don't need to know how to go back to master.
        paskozdilar 5y ago
- jrockway 5y ago
  Git tags are completely orthogonal. When your main branch starts being v2, you only have to change go.mod to tack a v2 onto the end and keep your source code in the same place. "go get example.com/you/v2" will fetch exmaple.com/you from the main branch, read the go.mod file to see that it's v2, and continue. You don't have to actually create a v2 directory, or keep your old version in the main branch. (If you do tag releases, then "go get example.com/you/v2@v1.2.3" won't work, though.)
  - Dylan16807 5y ago
    Well now I'm extra confused. If you do that, what command would you type to get "the most recent v1" now? How would it find it?

tkiolp4 5y ago

It’s an elegant solution for packages that don’t use versioning features like git tags. For every other package out there that uses git tags, it’s just a lazy solution: why on earth would I want to specify the version in the path? Git tags solves that problem in a more elegant way (both from the side of the maintainers and users).

paskozdilar 5y ago
> it’s just a lazy solution: why on earth would I want to specify the version in the path? It's not a lazy solution, just opinionated. Personally, I love the fact that just by seeing the import path I know exactly which codebase is used. I don't have to open my go.mod, see which version I'm using, clone the repository, dig through the history to check out a specific tag and see what code is actually used in my program... I just open the repo in my browser and browse through the directories. There isn't a single system on earth that doesn't support directories! I also love the fact that I don't have to know s**t about git to use Go. If Go was to suddenly switch to git tags, not only would it break a massive amounts of existing code, but would basically force everyone to learn about git tags just to be able to see what code are they using, which would raise the amount of paperwork I have to fill in order to work on the thing I care about. Go is fundamentally against needless paperwork.
- Dylan16807 5y ago
  > I just open the repo in my browser and browse through the directories. Browse via what? It would be entirely reasonable, not weird at all, if git.example/user/repo/ showed a list of branches and tags. And then it would actually be easier to reach git.example/user/repo/v3/ than to reach git.example/user/repo/master/v3/ The particular way github does directories isn't canonical. And if you wanted to clone the repo, you could clone a specific branch easily. When it comes to minor versions, you have to dig anyway to see the matching source under the current system.
  - paskozdilar 5y ago
    > Browse via what? Via whatever tool you have available. Most projects also have a download link or a clone command written, in case the remote repo doesn't support in-browser file listing, so you can download it and browse locally, without needing to checkout tag or whatever. > if you wanted to clone the repo, you could clone a specific branch easily. Unless I don't know how to clone a specific branch - in which case I need to learn about git branches, figure out how they work, and how to clone a specific branch, and how to go back to master etc. etc. etc. In contrast to just cloning the repo and browsing the v2/ directory.
    - Dylan16807 5y ago
      You blew past my main point, which is that if you go to browse an entire repo online, there's no reason that a v2/ directory will be easier to find than a v2/ branch, unless you're specifically assuming the site looks like github. > In contrast to just cloning the repo and browsing the v2/ directory. "just" cloning the repo? You gave this list of arduous steps for why cloning a tag is harder than browsing, but "just" cloning the repo still makes you do all but one of those steps! And if something is generating the clone command for you, it can add "-b". You don't need to know how git branches work. You definitely don't need to know how to go back to master.
      - paskozdilar 5y ago
jrockway 5y ago
Git tags are completely orthogonal. When your main branch starts being v2, you only have to change go.mod to tack a v2 onto the end and keep your source code in the same place. "go get example.com/you/v2" will fetch exmaple.com/you from the main branch, read the go.mod file to see that it's v2, and continue. You don't have to actually create a v2 directory, or keep your old version in the main branch. (If you do tag releases, then "go get example.com/you/v2@v1.2.3" won't work, though.)
- Dylan16807 5y ago
  Well now I'm extra confused. If you do that, what command would you type to get "the most recent v1" now? How would it find it?