previously valid amazon environment now invalid?

[Michael Hudson-Doyle]

On 30 April 2015 at 07:40, Nate Finch <nate.finch at canonical.com> wrote:
> We have done it before.  As Roger said, there is/was a convention to do a
> three step process to deprecate old command line functionality.
>
> There's a big difference between what the command line looks like, and
> keeping compatibility with 1.18.  We might want to preserve both, but
> they're not the same thing.

I would say that they are the same thing.

> For example, a 1.25 client that renames --constraints as --require is still
> compatible with 1.18, as long as it can read the environments.yaml, jenv,
> and communicate with the 1.18 server correctly.

No.  Remember that new juju versions go in their entirety into
-updates of the LTS release, which is enabled by default. We *cannot*
*cannot* *cannot* break the scripts of people who just install trusty
off the usb stick and let software updater do its thing.

There is another path here, which would be to backport bugfixes only
into -updates.  That would be a different kind of pain and someone
(not me) made the assessment that the pain of maintaining 100%
compatibility with the version that was included with the first LTS
release would be less than the pain of making targeted backports (and
although it wasn't me, I think they were probably right).

(I guess a third option would be some kind of  "trusty compatibility
mode" that is activated by looking at lsb-release or something but
that also sounds horrible).

> I would not say that, by most people's assessment, "compatibility with 1.18"
> is the same as "compatibility with bash scripts that scripted against a 1.18
> client".

Er. I'm pretty sure IS would disagree.

Cheers,
mwh