Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: provide support for VCS branches in go get / import #6174

Closed
gopherbot opened this Issue Aug 16, 2013 · 7 comments

Comments

Projects
None yet
4 participants
@gopherbot
Copy link

gopherbot commented Aug 16, 2013

by tv@duh.org:

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.
@gopherbot

This comment has been minimized.

Copy link
Author

gopherbot commented Aug 16, 2013

Comment 1 by tv@duh.org:

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?
@robpike

This comment has been minimized.

Copy link
Contributor

robpike commented Aug 17, 2013

Comment 2:

Labels changed: added priority-later, go1.3maybe, removed priority-triage, go1.2maybe.

Status changed to Accepted.

@robpike

This comment has been minimized.

Copy link
Contributor

robpike commented Aug 20, 2013

Comment 3:

Labels changed: removed go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

rsc commented Nov 27, 2013

Comment 4:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

rsc commented Dec 4, 2013

Comment 5:

Labels changed: added release-none, removed go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

rsc commented Dec 4, 2013

Comment 6:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@bcmills

This comment has been minimized.

Copy link
Member

bcmills commented Jan 18, 2019

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).

I believe that modules address exactly that use-case. Give them a try! 🙂

@bcmills bcmills closed this Jan 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.