5 ms·

The Go Team has actually communicated this matter extensively through your blog (https://blog.golang.org/v2-go-modules https://blog.golang.org/v2-go-modules).

brabel 6y ago
This is mentioned in the article. The problem is that the official solution, as mentioned in the article, seems really bad... you just have to copy the whole project into the `v2` folder, then do the same for a future `v3` and so on... it kind of goes against normal practices of using version control tools for this kind of thing, where each version would be in a different branch, not folder. Not to mention having duplicate files like this can make finding files in your editor a bit confusing as well. Though I like how Go solved dependency management and dared to go on a different path than almost every other package manager, this particular solution seems to go a bit too far?!
- jimktrains2 6y ago
  > kind of goes against normal practices of using version control tools for this kind of thing, where each version would be in a different branch, not folder. I mean, it goes against how got works. SVN does the branch-in-a-folder thing, so it's not anathema to "version control". That said, as for branch-in-a-folder, "thanks, I hate it".
- rossmohax 6y ago
  Copying into versioned folder is probably how large monorepos work. If so, then it is another example of Google influence on Go even though core team denies it.
- kardianos 6y ago
  No, you just tag a v2 release like "git tag v2.0.0" and ensure your module path has a /v2. That's not hard.
  - donatj 6y ago
    As the post states, both are valid, but this method is not backwards compatible.
    - xyzzy_plugh 6y ago
      I'd say being backwards compatible is an edge case, in this instance. Most folks don't use older versions of go.
- vlowther 6y ago
  Or you could just have separate branches for major versions. That works too, and everyone seems to forget it.
  - jpttsn 6y ago
    I do only this. Copying the codebase into a subdirectory seems like a kluge. It baffles me that they recommend that solution; seems like too much backward compatibility.

brabel 6y ago

This is mentioned in the article. The problem is that the official solution, as mentioned in the article, seems really bad... you just have to copy the whole project into the `v2` folder, then do the same for a future `v3` and so on... it kind of goes against normal practices of using version control tools for this kind of thing, where each version would be in a different branch, not folder. Not to mention having duplicate files like this can make finding files in your editor a bit confusing as well. Though I like how Go solved dependency management and dared to go on a different path than almost every other package manager, this particular solution seems to go a bit too far?!

jimktrains2 6y ago
> kind of goes against normal practices of using version control tools for this kind of thing, where each version would be in a different branch, not folder. I mean, it goes against how got works. SVN does the branch-in-a-folder thing, so it's not anathema to "version control". That said, as for branch-in-a-folder, "thanks, I hate it".
rossmohax 6y ago
Copying into versioned folder is probably how large monorepos work. If so, then it is another example of Google influence on Go even though core team denies it.
kardianos 6y ago
No, you just tag a v2 release like "git tag v2.0.0" and ensure your module path has a /v2. That's not hard.
- donatj 6y ago
  As the post states, both are valid, but this method is not backwards compatible.
  - xyzzy_plugh 6y ago
    I'd say being backwards compatible is an edge case, in this instance. Most folks don't use older versions of go.
vlowther 6y ago
Or you could just have separate branches for major versions. That works too, and everyone seems to forget it.
- jpttsn 6y ago
  I do only this. Copying the codebase into a subdirectory seems like a kluge. It baffles me that they recommend that solution; seems like too much backward compatibility.