<div dir="ltr">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 some of the problems we've seen with godeps.  <div>
<br></div><div>I think the way we constantly break the APIs of our packages right now is awful.  No one will rely on our code, because our code isn't reliable.  I, myself, would not even rely on our code, and I think that's quite a shame.   This is a bad foot to put forward, and it's relatively easy to avoid.  </div>
<div><br></div><div>Yes, changing versions of a package causes some code churn, but often times, if you have to change the import path, you're going to have to change the code that uses it, since by definition, you're breaking the API.  And changing one or two characters in the import statement of even a large number of files is not really a huge deal, especially since it can be done programmatically.</div>
<div><br></div><div>-Nate</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 3, 2014 at 4:07 AM, roger peppe <span dir="ltr"><<a href="mailto:rogpeppe@gmail.com" target="_blank">rogpeppe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 3 June 2014 00:13, Nate Finch <<a href="mailto:nate.finch@canonical.com">nate.finch@canonical.com</a>> wrote:<br>

> Right now, we change tip on our repos outside of Juju-core with breaking API<br>
> changes.  This is not the way to make packages that others can use and<br>
> depend on.  Since we are in the process of moving many/most/all of these<br>
> dependencies to github, I think it would be an opportune time to start being<br>
> better about how we maintain these projects.<br>
><br>
> The main way to do this in Go is to use versioned URLs, the way<br>
> <a href="http://labix.org/v2/mgo" target="_blank">labix.org/v2/mgo</a> and <a href="http://gopkg.in" target="_blank">gopkg.in</a> use them.  I suggest we set up a facility to<br>
> do this so that if other people are using our code, we won't break them<br>
> every time we need to change the API of one of our packages.<br>
><br>
> It also would mean reduced reliance on godeps (in theory we could get to the<br>
> point of not needing it at all), which would be a good thing.<br>
<br>
</div></div>No, use of godeps (or Keith Rarick's godep, which I think we should probably<br>
move towards using) is orthogonal to the use of versioned URLs.<br>
<br>
Versioned URLs give us (or provide to others) stable APIs, so you are guaranteed<br>
to be able to *compile* packages, but they don't give or provide guaranteed<br>
*behaviour*, which is crucial for us to get repeatable builds.<br>
<br>
So while I agree that it would be nice to move towards a versioned Juju<br>
API, we still need to use godeps.<br>
<br>
FWIW, I think it would be more than nice - it's actually very important that<br>
we start to export versioned APIs, at least for selected parts of the project,<br>
because external projects will start to depend on the Juju API and<br>
will need it to be stable.<br>
<br>
Initially, I'd suggest that we at least provide a stable API that<br>
allows third-party<br>
code to:<br>
<br>
- bootstrap, open and destroy environments<br>
- interact with the API<br>
<br>
It might be a good moment to stand back and consider what we actually<br>
want that package API to look like and perhaps making a package that layers on<br>
top of existing code that provides that.<br>
<br>
  cheers,<br>
    rog.<br>
</blockquote></div><br></div>