On 5 April 2016 at 23:35, Martin Packman <martin.pack...@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? -- Stuart Bishop <stuart.bis...@canonical.com> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
