Re: backward compatibility
On Mon, Oct 30, 2017 at 01:33:40PM +0400, John Meinel wrote: > I think saying that we offer "we will allow clients that are <1yr old to > stay compatible with current controllers", and vice versa seems ok, and > doesn't seem like a significant maintenance burden. (we could at least > release a new 2.X if we broke compatibility with 2.(X-2).) As someone who's been upgrading a fair few Juju environments lately, I would say my expectation has always been interoperability with minor releases, I wouldn't expect different major version upgrades and controllers on different major versions to maintain backward compatibility. I think it's also important that wherever the line is drawn, `juju upgrade-juju` without specifying version is clever enough to not get a user into a state where their environment is broken due to making an unsupported jump - i.e. upgrading the model to 2.4 whilst the agents in the environment expected to take the upgrade are still 2.1 agents. Perhaps different rules as to what is supported from an upgrade/model migration perspective to what is generally supported makes sense? James > > John > =:-> > > > On Mon, Oct 30, 2017 at 8:22 AM, Anastasia Macmood < > anastasia.macm...@canonical.com> wrote: > > > Hi > > > > Now that we are settled on Juju 2, going forward we need to have a way > > to retire older minor versions in a user-friendly manner. > > > > We propose to use client/server version comparison to flag retiring > > versions in 3 distinct steps - deprecated, obsolete and unsupported. > > > > For example, we can determine that if your client version differs from > > your controller version by: > > > > * 2 minor versions, you are running a deprecated back-end; > > * 3 minor versions, you are running an obsolete back-end; > > * 4+ minor versions, you are running an unsupported backend. > > > > In this world, it means that when you are running a 2.4 client, you will > > be told that the controller on: > > > > * 2.2 is deprecated; > > * 2.1 is obsolete; > > * 2.0 is unsupported. > > > > This will be surfaced as a warning on 'juju status'. > > > > This approach will allow us to not just retire certain API versions, but > > also help triage bugs and set clear user expectations. Additional > > benefits for maintenance and support - we will not be carrying around > > huge amount of backward compatible code and craft... For example, does > > it really makes sense for us to carry around and cater for backward > > compatibility with Juju 2.0 when we are developing 2.6? > > > > Thoughts? > > > > Sincerely Yours, > > > > Anastasia > > > > > > -- > > Juju-dev mailing list > > Juju-dev@lists.ubuntu.com > > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > > mailman/listinfo/juju-dev > > > -- > Juju mailing list > j...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju -- James Hebden Cloud Reliability Engineer BootStack Squad @ Canonical Ltd. signature.asc Description: PGP signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: backward compatibility
So I think its fine for giving feedback from client against a controller (new client, old controller). Though how often we want to warn, have a way to disable the warning (for how long, etc)? The other side seems more difficult, as far as 2.0 client talking to a 2.4 controller. We could start assuming we're going to deprecate today, and just start writing the 2.4 client to warn if you're running against a 2.8+ controller. I think as for what we actually *support* (as in, be willing to make a release if we break compatibility) is possibly even only 1 minor version. It is also interesting to consider how we convey to users of the API (aside from the Juju client itself), that they are running against older versions of the Facades. They know that they are when they connect and inspect the available versions. So they *could* inform the user, but there isn't any sort of inherit pressure we put on them to do so. I think saying that we offer "we will allow clients that are <1yr old to stay compatible with current controllers", and vice versa seems ok, and doesn't seem like a significant maintenance burden. (we could at least release a new 2.X if we broke compatibility with 2.(X-2).) John =:-> On Mon, Oct 30, 2017 at 8:22 AM, Anastasia Macmood < anastasia.macm...@canonical.com> wrote: > Hi > > Now that we are settled on Juju 2, going forward we need to have a way > to retire older minor versions in a user-friendly manner. > > We propose to use client/server version comparison to flag retiring > versions in 3 distinct steps - deprecated, obsolete and unsupported. > > For example, we can determine that if your client version differs from > your controller version by: > > * 2 minor versions, you are running a deprecated back-end; > * 3 minor versions, you are running an obsolete back-end; > * 4+ minor versions, you are running an unsupported backend. > > In this world, it means that when you are running a 2.4 client, you will > be told that the controller on: > > * 2.2 is deprecated; > * 2.1 is obsolete; > * 2.0 is unsupported. > > This will be surfaced as a warning on 'juju status'. > > This approach will allow us to not just retire certain API versions, but > also help triage bugs and set clear user expectations. Additional > benefits for maintenance and support - we will not be carrying around > huge amount of backward compatible code and craft... For example, does > it really makes sense for us to carry around and cater for backward > compatibility with Juju 2.0 when we are developing 2.6? > > Thoughts? > > Sincerely Yours, > > Anastasia > > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
backward compatibility
Hi Now that we are settled on Juju 2, going forward we need to have a way to retire older minor versions in a user-friendly manner. We propose to use client/server version comparison to flag retiring versions in 3 distinct steps - deprecated, obsolete and unsupported. For example, we can determine that if your client version differs from your controller version by: * 2 minor versions, you are running a deprecated back-end; * 3 minor versions, you are running an obsolete back-end; * 4+ minor versions, you are running an unsupported backend. In this world, it means that when you are running a 2.4 client, you will be told that the controller on: * 2.2 is deprecated; * 2.1 is obsolete; * 2.0 is unsupported. This will be surfaced as a warning on 'juju status'. This approach will allow us to not just retire certain API versions, but also help triage bugs and set clear user expectations. Additional benefits for maintenance and support - we will not be carrying around huge amount of backward compatible code and craft... For example, does it really makes sense for us to carry around and cater for backward compatibility with Juju 2.0 when we are developing 2.6? Thoughts? Sincerely Yours, Anastasia -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
