> If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project!
The alternative is of course supporting dozens or hundreds of copies of a library and every possible commit hash of said library. I contracted at a python shop that had 81 versions of a single library in use all pinned at different versions. The reason I know this is that I had the great joy of dealing with upgrading all of them after a critical hole was not only discovered (the company knew about it for some time, but just didn't want to bother updating all those apps) but exploited... repeatedly.
> it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)
If by "fixed" you mean there are dozens of solutions to pin versions -- then yes. If you mean baked into the go tool, then no.
But - but! Saying that you want your org to use one version of a library at a time is one thing. Saying that you want your code to use the latest version of every library is another thing altogether, however, and that's what "no version for github code" does, right?
"One version per org" means "upgrades are harder, but patches are easier and you don't need to deal with different quirks of different versions at the same time and you don't get problems using 2 components that need 2 different versions of some other thing in one process etc."
"Latest version, always" means you have no way to even build the latest version of your thing that was tested and is known to compile and work. Kinda sucks, I think.
Yes, I didn't pass judgement on the approach. It works well enough for Google and avoids problems with e.g. ELF symbol conflicts. For development out on the open internet you do need some way to specify versions so it's a puzzling lack, but "if it works for Google it works for you" does seem to be a recurring theme in the Go design.
The alternative is of course supporting dozens or hundreds of copies of a library and every possible commit hash of said library. I contracted at a python shop that had 81 versions of a single library in use all pinned at different versions. The reason I know this is that I had the great joy of dealing with upgrading all of them after a critical hole was not only discovered (the company knew about it for some time, but just didn't want to bother updating all those apps) but exploited... repeatedly.
> it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)
If by "fixed" you mean there are dozens of solutions to pin versions -- then yes. If you mean baked into the go tool, then no.