Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: provide support for VCS branches in go get / import #6174
Running go1.1.2 -- but as far as I can tell, this hasn't been filed as an actual issue yet. Basically, the vcs-based checkouts are now pretty flexible (even when not from a well-known hosting service), but there is no syntax for checking out a branch other than the vcs's "default" branch. Something as simple as "example.org/foo/projname.vcs::branchname/bar/baz" as the URL syntax might be good enough. How this is stored on disk to prevent conflicts would likely be more complicated, perhaps as separate parallel directories of some fashion. Note that this is not the same goal as in issue #5779. Here, I'm talking about giving a third-party library creator the ability to supply generationally stable APIs for that library (irrespective of Go language version, for which build constraints are probably sufficient for now). For instance, the main development branch of example.org/mylibrary.git may contain a refactor/rethink of how fundamental logic works, but this requires an API-call rework by all downstream applications. The author could provide a "1.x-stable" branch, or other indicative name, to keep changes as compatible as possible without impeding new development.
Comment 1 by email@example.com:
BTW, yes, I know this has been discussed on golang-nuts. There's one thing to be said for avoiding *exact* version number dependencies -- that way lies teh stupeed of Maven -- but forcing access to only *one branch* on API consumers is a direct impediment to significant evolutionary changes in third-party libraries. Effectively, an evolutionary change then means that the third party must create a completely independent VCS repo so the namespace is separate from Go's import syntax... for what advantage?