<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 5, 2016 at 1:37 PM Martin Packman <<a href="mailto:martin.packman@canonical.com">martin.packman@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/04/2016, Adam Collard <<a href="mailto:adam.collard@canonical.com" target="_blank">adam.collard@canonical.com</a>> wrote:<br>
> Will there be a transitional release of 1.25.x that also gives us a juju1<br>
> binary to facilitate this?<br>
<br>
Yes, the plan entails both an update to the juju in main for the 2.0<br>
release and a new juju 1.25 in universe that cooperates with the<br>
changes.<br>
<br>
For the debian packaging nitty gritty, what we had before was:<br>
<br>
Archive:<br>
  juju (depends juju-core)<br>
    juju-core (/usr/bin/juju etc)<br>
  juju-local (depends juju-core, juju-mongodb, lxc bits)<br>
  juju-local-kvm (depends juju-core, juju-mongodb, libvirt bits)<br>
<br>
Devel PPA:<br>
  juju2 (/usr/bin/juju2 etc)<br>
<br>
We have the following proposed:<br>
<br>
Main:<br>
  juju (depends juju-2.0, suggests juju-core)<br>
    juju-2.0 (/usr/lib/juju-2.0/bin/juju, linked as /usr/bin/juju and<br>
wrapped as /usr/bin/juju-2.0)<br>
<br>
(The lxd provider is bundled, replacing the local packaging bits for 2.0).<br>
<br>
Universe:<br>
  juju-core (transitional depends juju-1.25)<br>
  juju-1 (depends juju-1.25)<br>
    juju-1.25 (/usr/lib/juju-1.25/bin/juju, wrapped as /usr/bin/juju-1)<br>
  juju-local (depends juju-1.25, juju-mongodb, lxc bits)<br>
  juju-local-kvm (depends juju-1.25, juju-mongodb, libvirt bits)<br>
<br>
When upgrading, you keep your juju package and upgrade juju-core to<br>
the new 1.X packaging, and pick up the new 2.0 package. With a fresh<br>
install, you just get 2.0 unless you ask for juju-1 as well or take<br>
the suggests.<br></blockquote><div><br></div><div>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 :)</div></div></div>