New juju in ubuntu

[Marco Ceppi]

On Wed, Apr 6, 2016 at 10:07 AM Stuart Bishop <stuart.bishop at canonical.com>
wrote:

> On 5 April 2016 at 23:35, Martin Packman <martin.packman at canonical.com>
> wrote:
>
> > The challenge here is we want Juju 2.0 and all the new functionality
> > to be the default on release, but not break our existing users who
> > have working Juju 1.X environments and no deployment upgrade path yet.
> > So, versions 1 and 2 have to be co-installable, and when upgrading to
> > xenial users should get the new version without their existing working
> > juju being removed.
> >
> > There are several ways to accomplish that, but based on feedback from
> > the release team, we switched from using update-alternatives to having
> > 'juju' on xenial always be 2.0, and exposing the 1.X client via a
> > 'juju-1' binary wrapper. Existing scripts can either be changed to use
> > the new name, or add the version-specific binaries directory
> > '/var/lib/juju-1.25/bin' to the path.
>
> How do our plugins know what version of juju is in play? Can they
> assume that the 'juju' binary found on the path is the juju that
> invoked the plugin, or is there some other way to tell using
> environment variables or such? Or will all the juju plugins just fail
> if they are invoked from the non-default juju version?
>

You can invoke `juju version` from within the plugin and parse the output.
That's what I've been doing when I need to distinguish functionality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160406/985d6a0d/attachment.html>