API compatibility policy and practices between juju versions

[Ian Booth]

On 20/11/13 09:47, Nate Finch wrote:
> Non-matching client and server seems like crack for anything other than
> status and upgrade. Possibly only upgrade. Is there a reason we can't just
> require everyone to upgrade in lockstep and warn if not?
> On Nov 19, 2013 6:06 PM, "Curtis Hovey-Canonical" <curtis at canonical.com>
> wrote:
>

It used to be a lot worse - we used to only match tools based on major version
number. When that was changed to major.minor matching, there was a bit of teeth
gnashing but the issues around mismatches are now apparent for all to see.

We can't enforce a full system wide upgrade because that's not how most
enterprise IT people manage their deployments. They like to be cautious and test
any upgrade on a subset of systems, plus it is often not practical to upgrade
all servers at once. So they need to be able to use version 1.X client to talk
to both 1.X and 1.Y servers.

The initial thought was that moving to major.minor version matching, although
not ideal, would allow the compatibility we are looking for. However, the fact
that the API is still evolving means we are not there yet. I *believe* the aim
is to get the client to fully sit on top of the API prior to 1.18 shipping and
from that point, client backwards compatibility of some form will be mandated. I
personally believe that should extend to major version backwards compatibility
ie any 1.X version client can talk to any 1.Y version server. With a (hopefully)
stable client API in place for 1.18, this should become an achievable goal,
where any special casing to handle version differences should be the rare
exception rather than the norm; hence the burden of supporting older server
versions with newer clients should be manageable.