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 < [email protected]> wrote: > Resend to the list. > > > On Tue, Nov 19, 2013 at 11:42 PM, John Meinel <[email protected]> > 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
