API compatibility policy and practices between juju versions

[William Reade]

The underlying assumption was originally that tools versions would change
much more frequently than client versions, but this hasn't been borne out
in practice -- as you note, this is all a consequence of the rapid CLI ->
API changes. But if the known-issue handwave wasn't good enough for
1.16.3->1.16.4 -- and you're right, it wasn't -- it's certainly not going
to be enough for 1.16.x->1.18.x.

Since we don't expect schema upgrades to be a practical reality until 2.0
-- and since we don't want to blow through a load of major version numbers
in the interim -- I think we have no choice but to have the CLI fall back
to using direct DB access when it's communicating with an out-of-date state
server. The only actual downside of providing proper compatibility is that
the code is boring to write, and that's no excuse not to do it.

FWIW, I *am* comfortable with the idea that we can only guarantee
compatibility between 1.x and 1.x+2, for even x -- thus allowing us to
retire direct db-access CLI code at a reasonable rate -- but that needs to
be in *both* directions, as we always planned and agreed. And even then,
only on the understanding that this state of affairs persists *only* until
2.0, after which we cannot drop 2.0 compatibility until 3.0, however far
2.x might take us.

Counterarguments?

Cheers
William



On Wed, Nov 20, 2013 at 9:26 PM, Curtis Hovey-Canonical <
curtis at canonical.com> wrote:

> Resend to the list.
>
>
> On Tue, Nov 19, 2013 at 11:42 PM, John Meinel <john at arbash-meinel.com>
> wrote:
> > I know William and I are well aware that 1.18 cli wont work with a 1.16
> > server (and most likely the reverse is true).
> > Agent compatibility is actually easy at this point because we have that
> all
> > in the API already. CLI compat is something we've explicitly skipped.
> >
> > I would  love to support it and will certainly require it post 2.0. Is it
> > worth spending the time now?
>
> I think we have a numbers problem. I believe savvy users will accept
> incompatibilities between major numbers. 0, 1, and 2 imply different
> foundations. 1.16 and 1.18 imply additional features, not the removal
> of them. If 1.18 cannot help 1.16 upgrade to 1.18, we offer ways to
> have co-installs of both.
>
> Alternatively, if this is just about the transition about cli to api,
> we write a make this clear in the known issues, explain how we think
> small organisations and large enterprises will accomplish the upgrade.
> We will also accept that many will refuse to upgrade because the
> barrier is too high, just as users have done with pyjuju,
>
> Honestly. as much as I want to see 1.18 this month, I don't think it
> can happen this year. If we make upgrades hard, we will stop work on
> features after the 1.18 release to address the concerns of
> organisations that cannot complete upgrades.
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20131120/bbbe5cfd/attachment-0001.html>