Some of you will be aware of the excitement over the last week getting Juju 2.0 into Xenial, this is an update mail so everyone knows what the goal is with the user experience.
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. Because the meaning of 'juju' is changing, we want to give a on-first-run message about how to work with any existing environments the user may have. That work is covered by: <https://bugs.launchpad.net/juju-core/+bug/1564622> The best way to detect seems to be, when creating the new configuration for 2.0, if ~/.juju or JUJU_HOME is set, use the series to suggest ways to access or install the 1.X client. There were some other interesting points from review. The way we do plugins both leads to large binaries with a lot of duplication, and means the only sane way to deal with multiple juju versions is through path manipulation. If anyone is wants to distribute juju plugins, they'll need to watch out for this. See this bug on the binary sizes: <https://bugs.launchpad.net/juju-core/+bug/1564677> Also we've had to avoid stripping the juju binaries, which is otherwise standard distro practice, as it was unsupported and go 1.2 breaks. With the switch to go 1.6 it seems like this may now work as expected, but needs to go through testing: <https://bugs.launchpad.net/juju-core/+bug/1564662> We also have some ongoing questions over golang packaging in the distro as a whole, but have demonstrated we an split out and create seperate golang-*-dev packages for nearly all the juju dependencies as needed. We hope to avoid most of the pain from this packaging process next cycle by putting our alpha releases into the devel disto (Y 16.10), rather than just adding them to our PPA. This will not need to replace the 2.0 version if we have compatibility concerns with early versions given the packaging changes from this cycle, but we will also be back to no-breakage mode as well. Martin -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
