Will there be a transitional release of 1.25.x that also gives us a juju1 binary to facilitate this? On Tue, 5 Apr 2016 at 19:36, Martin Packman <martin.pack...@canonical.com> wrote:
> 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 >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
