That's all spot on: godep and versioning the API for compatibility
purposes are orthogonal concepts, versioning the API for compatibility
purposes _helps_ godep's case, and changing import paths is trivial.
I don't personally mind if you use gopkg.in specifically or not, but
I'd strongly recommend
I vote for KR's godep
On Tue, Jun 3, 2014 at 8:21 PM, Nate Finch wrote:
> Ian makes a good point about repeatable builds. I had actually come to the
> same conclusion as Rog overnight, that they are orthogonal, so we can do
> both. I agree with Rog, moving to Keith Rarick's godep is probably th
Ian makes a good point about repeatable builds. I had actually come to the
same conclusion as Rog overnight, that they are orthogonal, so we can do
both. I agree with Rog, moving to Keith Rarick's godep is probably the
right move. It has a lot more usage than Rog's godeps, and I think avoids
som
On 3 June 2014 00:13, Nate Finch wrote:
> Right now, we change tip on our repos outside of Juju-core with breaking API
> changes. This is not the way to make packages that others can use and
> depend on. Since we are in the process of moving many/most/all of these
> dependencies to github, I thi
I agree with the general thrust of the point being made but until Go (or more
accurately he Go community) agrees on a sane dependency management model I can't
see how we can move away from godeps. Even if we attempt to use versioned import
URLs (which make me very sad due to the pointless code chur
Right now, we change tip on our repos outside of Juju-core with breaking
API changes. This is not the way to make packages that others can use and
depend on. Since we are in the process of moving many/most/all of these
dependencies to github, I think it would be an opportune time to start
being b
