On Thu, 30 Apr 2015, Nate Finch wrote: > If someone needs 1.18 CLI compatibility, they can use 1.18. It's that > simple. We're maintaining API compatibility for just this reason. If they > don't want the binary to change, they shouldn't update it (or should just > rename it to juju-1.18 or something). > > We shouldn't break the CLI willy-nilly, but given sufficient reason, it > can, and should change, IMO.
This is something we should really think long/hard about. Users running trusty expect an LTS release to be safe to upgrade to. As long as Juju versions are backported to LTS releases Juju has the responsibility of being repeatable to those LTS users and their deployment and management scripts. It sucks, but it's the cost of getting the newer releases into the LTS product. That being said, the cli is an API. It's the user facing API. Users don't care about how the internals between the client and server work, as long as the client is working for them. APIs can have new endpoints added without issue as there's no risk to breakage of the API usage. I think if we look at the CLI as an API and treat backward incompatible changes as 'needs a version bump' then it'll help identity the points where we need to look at some sort of way to do 'compatibility mode' or such. Rick -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
