api/cli compatability between juju minor versions

Curtis Hovey-Canonical curtis at canonical.com
Fri Jul 25 19:56:14 UTC 2014


Ladies and Gentlemen.

The Juju QA meet with Robie Basak to discuss backporting juju 1.20.x
to trusty. Robie was planning to supersede 1.18.1 with 1.20.2. I
suffered an anxiety attack.

My current understanding is that we promise API/CLI compatibility
between one minor version and the next. Features are can be
deprecated, and they can be removed in the next minor release. Thus
  1.18.1 > 1.20.2 will work
  1.18.1 > 1.21.0 may not work

This scenario outline what can happen:

    An enterprise machine uses trusty and juju 1.18.1 It manages several
    permanent 1.18.x environments [1]. The machine also has several juju
    scripts to create and destroy juju envs to do ephemeral work.
    The machine doesn't get package updates from 1 year.

    Package updates are enabled; juju 1.25.0 is installed. The users of
    the machine didn't see the package was updated, they know nothing of
    the new features. Can they still manage there eternal 1.18.x envs? Do the
    automated scripts continue to create and destroy ephemeral envs [2]

As Ubuntu promises stability within a series, we cannot replace a well
understood juju with newer version of juju that redefines or removed
features.

I know that the client is responsible for provisioning during
bootstrap and add-machine. Redefinitions of behaviours can happen. I
think they already have. For example, I see
    commit 5d0c7aeb7d3049672df587cb11f455465cce4a57
   [bug=1302005] cmd/juju: deprecate --series, added --upload-series
introduced in 1.19.2 as a planned change. 1.20.2 still supports
--series. I can see that 1.21-alpha1 still supports --series, but when
is --series obsoleted?

If Juju is going to promise api/cli compatibility support for more
than 1 minor version, how long do we support? 2 years? Precise is more
than 2 years and we see the series is still popular.

Eventually, Juju will want to break compatibility, maybe it will need
to. Ubuntu will need to create co-installable packages. Users will
knowingly install newer version of juju to get new features. Old
versions will still be installed an usable. User can reinstall old
versions if they discover compatibility issues they cannot mitigate
quickly.

[1] We know that trusty 1.18.1 client users are deploying and
upgrading envs to 1.18.4. We know these version are compatible

[2] The new envs will be 1.24.x

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui



More information about the Juju-dev mailing list