backward compatibility

Anastasia Macmood anastasia.macmood at
Mon Oct 30 04:22:52 UTC 2017


Now that we are settled on Juju 2, going forward we need to have a way
to retire older minor versions in a user-friendly manner.

We propose to use client/server version comparison to flag retiring
versions in 3 distinct steps - deprecated, obsolete and unsupported.

For example, we can determine that if your client version differs from
your controller version by:

  * 2 minor versions, you are running a deprecated back-end;
  * 3 minor versions, you are running an obsolete back-end;
  * 4+ minor versions, you are running an unsupported backend.

In this world, it means that when you are running a 2.4 client, you will
be told that the controller on:

  * 2.2 is deprecated;
  * 2.1 is obsolete;
  * 2.0 is unsupported.

This will be surfaced as a warning on 'juju status'.

This approach will allow us to not just retire certain API versions, but
also help triage bugs and set clear user expectations. Additional
benefits for maintenance and support - we will not be carrying around
huge amount of backward compatible code and craft... For example, does
it really makes sense for us to carry around and cater for backward
compatibility with Juju 2.0 when we are developing 2.6?


Sincerely Yours,


More information about the Juju mailing list