On Wed, Apr 6, 2016 at 10:07 AM Stuart Bishop <[email protected]> wrote:
> On 5 April 2016 at 23:35, Martin Packman <[email protected]> > 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.
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
