On Tue, Apr 5, 2016 at 1:37 PM Martin Packman <[email protected]> wrote:
> On 05/04/2016, Adam Collard <[email protected]> wrote: > > Will there be a transitional release of 1.25.x that also gives us a juju1 > > binary to facilitate this? > > Yes, the plan entails both an update to the juju in main for the 2.0 > release and a new juju 1.25 in universe that cooperates with the > changes. > > For the debian packaging nitty gritty, what we had before was: > > Archive: > juju (depends juju-core) > juju-core (/usr/bin/juju etc) > juju-local (depends juju-core, juju-mongodb, lxc bits) > juju-local-kvm (depends juju-core, juju-mongodb, libvirt bits) > > Devel PPA: > juju2 (/usr/bin/juju2 etc) > > We have the following proposed: > > Main: > juju (depends juju-2.0, suggests juju-core) > juju-2.0 (/usr/lib/juju-2.0/bin/juju, linked as /usr/bin/juju and > wrapped as /usr/bin/juju-2.0) > > (The lxd provider is bundled, replacing the local packaging bits for 2.0). > > Universe: > juju-core (transitional depends juju-1.25) > juju-1 (depends juju-1.25) > juju-1.25 (/usr/lib/juju-1.25/bin/juju, wrapped as /usr/bin/juju-1) > juju-local (depends juju-1.25, juju-mongodb, lxc bits) > juju-local-kvm (depends juju-1.25, juju-mongodb, libvirt bits) > > When upgrading, you keep your juju package and upgrade juju-core to > the new 1.X packaging, and pick up the new 2.0 package. With a fresh > install, you just get 2.0 unless you ask for juju-1 as well or take > the suggests. > A funny side-effect of this is `juju 1` and `juju 2.0` are now valid commands since they follow the plugin format. Which means `juju 1 2.0 status` would invoke the juju-2.0 bin and run the `juju-1` bin which would then run the `juju-2.0` bin again before finally querying status :)
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
