This is why we want to make a juju library, so we have a package that we know we need to keep backwards compatibility with. Sure, you can vendor or pin the revision, but that doesn't help you when a new feature or fix lands and you update, and everything breaks. If we have a library we try to keep backwards compatible, then these problems would be minimized.
On Fri, Aug 12, 2016 at 1:56 PM roger peppe <roger.pe...@canonical.com> wrote: > On 12 August 2016 at 14:11, Nate Finch <nate.fi...@canonical.com> wrote: > > No other repo should ever depend on github.com/juju/juju. > > I have to call this out. There is no decent way to use Juju from Go without > depending on github.com/juju/juju. > > And backward compatibility isn't insurmountable - dependencies can be > locked or > vendored. Juju itself uses many non-backwardly compatible > dependencies, after all. > > I think we should be aiming to provide a nice Go API to Juju, whether that > ends > up in github.com/juju/juju or not. > > cheers, > rog. >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
