tl;dr: godeps overrides gopkg.in, so you can have godeps pin a commit from a different branch than gopkg.in is retrieving (i.e. make a release-number branch, like "1.22" and use godeps to pin commits from there, even if go get & gopkg.in is getting a different branch).
The long story: There was an interesting problem today - we needed to update the license in 1.22 for gopkg.in/juju/charm.v4 to properly assign copyright to Canonical. This may sound trivial, but it's not, because we are using godeps to pin commits, and there were several big changes made in charm.v4 after 1.22's release that we weren't really willing to just dump into 1.22. So we can't just fix the license on the v4 branch and update godeps to point at HEAD, because it would include all those new commits. Normally what you'd do is make a 1.22 branch off of the commit we have pinned and then make the change there, but then you're putting the change where gopkg.in can't get to it (it only supports branches of the form vN[.N[.N]] and besides, we're already on v4). Well, with a little experimenting, we figured out you can just override gopkg.in with godeps. Turns out, godeps can pin a commit that isn't at all related to the branch that you've gotten from gopkg.in. So, for example, you can `go get gopkg.in/juju/charm.v4`, and gopkg.in will deliver you the code from the v4 branch of github.com/juju/charm. However, after it is downloaded, godeps can then set the code to a commit from the 1.22 branch. It's a little sneaky/inobvious/may make your future self mad at you... but it works. Note that you do *not* want to use the vN.NN form for this branch name, otherwise gopkg.in could accidentally deliver this code to someone who asks for v1 of your package, and since it's definitely *not* v1-compatible, they'd break. Eric and I took some time to figure all this out (and check that it actually works). And since this is probably something that will come up again, I figured it would be good to email everyone and save someone else from having to try to figure all this out again. Maybe everyone else already knew this, but I figured probably *someone* didn't, and chances are, that would just happen to be the person who had to do this next time. -Nate
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
