Being good citizens with our external repos
roger peppe
rogpeppe at gmail.com
Tue Jun 3 08:07:35 UTC 2014
On 3 June 2014 00:13, Nate Finch <nate.finch at canonical.com> 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 think it would be an opportune time to start being
> better about how we maintain these projects.
>
> The main way to do this in Go is to use versioned URLs, the way
> labix.org/v2/mgo and gopkg.in use them. I suggest we set up a facility to
> do this so that if other people are using our code, we won't break them
> every time we need to change the API of one of our packages.
>
> It also would mean reduced reliance on godeps (in theory we could get to the
> point of not needing it at all), which would be a good thing.
No, use of godeps (or Keith Rarick's godep, which I think we should probably
move towards using) is orthogonal to the use of versioned URLs.
Versioned URLs give us (or provide to others) stable APIs, so you are guaranteed
to be able to *compile* packages, but they don't give or provide guaranteed
*behaviour*, which is crucial for us to get repeatable builds.
So while I agree that it would be nice to move towards a versioned Juju
API, we still need to use godeps.
FWIW, I think it would be more than nice - it's actually very important that
we start to export versioned APIs, at least for selected parts of the project,
because external projects will start to depend on the Juju API and
will need it to be stable.
Initially, I'd suggest that we at least provide a stable API that
allows third-party
code to:
- bootstrap, open and destroy environments
- interact with the API
It might be a good moment to stand back and consider what we actually
want that package API to look like and perhaps making a package that layers on
top of existing code that provides that.
cheers,
rog.
More information about the Juju-dev
mailing list