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" <[email protected]> > 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. -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
