previously valid amazon environment now invalid?

[Nate Finch]

I would say the exact opposite. We *cannot* sacrifice the usability and
reliability of the product for all our future users just to keep a few
current users from having to update their scripts ever.

I am sure there will come a day when we decide that there is a change that
makes the client significantly better (safer/easier/more reliable), which
warrants breaking CLI compatibility. We did this with destroy-environment
fairly recently.  It was far too easy to destroy the wrong environment by
accident if you ran destroy-environment and weren't switched to the
environment you thought you were in, so we changed the command to require
you to type in the environment name.

If someone needs 1.18 CLI compatibility, they can use 1.18.  It's that
simple.  We're maintaining API compatibility for just this reason.  If they
don't want the binary to change, they shouldn't update it (or should just
rename it to juju-1.18 or something).

We shouldn't break the CLI willy-nilly, but given sufficient reason, it
can, and should change, IMO.

I suppose in theory we could have a compatiblity mode where you set
JUJU_118_COMPAT and the CLI functions just like 1.18, but given the fact
that they can just use 1.18, that seems like a lot of effort for little
benefit.
On Apr 29, 2015 6:29 PM, "Michael Hudson-Doyle" <
michael.hudson at canonical.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150430/db8944f2/attachment-0001.html>