Sorry, my reading of the article seemed to imply that I should have multiple copies of a project in a single repository, one for each major version?
That’s what branches and tags are for, so what am I missing?
That’s what branches and tags are for, so what am I missing?
go mod init example.com/program
go mod tidy
go build
Now, let's say the "github.com/foo/bar" module gets a backwards-incompatible change, but does not change the import path, and you attempt to do the above process again. This time, the go tool will download the incompatible version of "github.com/foo/bar" and the build will fail - or even worse, succeed but have some logic bugs that will go unnoticed until some massive shit happens.
I will agree that the ergonomics of this method aren't perfect by any means. But what it does accomplish, is that it forces you to declare your dependency explicitly (which seems to be one of Go's underlying principles).
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.
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.
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.
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.
> 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.
Absolutely not true. If you can "browse a repo", then by definition you can browse a directory inside a repo, so by definition you CAN do it. The option to choose a branch may or may not be there.
> "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!
When you install a package from a remote repository, the go tool clones it to ~/go/pkg/mod/, so you can open it locally and browse through the code, without even touching git. So yeah, it is "just" cloning the repo. Also it works with any popular VCS, not just git.
Again, you're assuming that it shows master first.
If it shows the list of branches first, then it's easier to find a branch than it is to find a subdirectory.
Both are equally valid ways to show a git repo.
> When you install a package from a remote repository, the go tool clones it to ~/go/pkg/mod/, so you can open it locally and browse through the code, without even touching git. So yeah, it is "just" cloning the repo. Also it works with any popular VCS, not just git.
Nothing says it has to use that method. The other way could be just as streamlined, if that was the layout people wanted to use.
This is a bizarre statement. You only care to look at v4 or v7, not nor whether you're looking at v7.5.9 that is actually used in your program, or at v7.6.4 which you never upgraded to?
> I also love the fact that I don't have to know s*t about git to use Go.
Go is actually about the only language that forces you to know Git (or other sccs) to do dependency management. Just look at how horrible it is to develop and release multiple Go modules from the same repository, requiring specific tag names and who knows what else.
Go mod is a terrible kludge and virtually every decision they've taken is simple only for the Go implementation team.