API compatibility policy and practices between juju versions

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-11-20 20:15, Curtis Hovey-Canonical wrote:
> On Tue, Nov 19, 2013 at 8:43 PM, Tim Penhey
> <tim.penhey at canonical.com> wrote:
>> It was my understanding that the api server needs to be at least
>> as advanced as any client.
>> 
>> This means that a 1.18 server should be able to support a 1.16.x
>> client.
>> 
>> However we don't support 1.18 clients on a 1.16.x server.
>> 
>> Does this change your thinking?
> 
> Newer clients with older servers is going to happen. How will
> devops upgrade their production deployments?
> 
> A. Nominate one deployment machine to go to 1.18. From another
> machine use juju 1.16 to call upgrade-juju. Run juju status on both
> machines to watch agent switch to the next version, or if they
> fail, intervene with the appropriate client? Scripting this is
> awkward (the kindest thing I can say).
> 
> B. We package co-installable juju clients. The deployment machine 
> installs juju1.16 and juju1.18. Devops and scripts take care to 
> specify the client version? Devops remove the unused clients when
> they remember. I am not sure how this would work with Windows. I am
> certain it wont work with OS X because homebrew only builds the
> most recent stable release.
> 
> Our current promise is that you can always upgrade to the next 
> version. I think we need to ensure this case works from 16 and 18 
> clients.
> 

Yes. I think that is one of the primary caveats for the "we don't
guarantee all cross version compatibility" is that we *do* guarantee
upgrade works. (It is the one blocker for making a .ODD release into a
.EVEN, which has delayed 1.14 and 1.16, IIRC)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKM4h8ACgkQJdeBCYSNAAN7lACguV6SMOTXennV++0Q27HLNGJN
JisAnj+Kmh52B0v7IBWtYqsiCbLklTlY
=BuMc
-----END PGP SIGNATURE-----