ntrollers 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
tional
> 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?
>
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 deve
