previously valid amazon environment now invalid?

[Nate Finch]

I think you're missing roger's point.  1.18 has some fallback code to
support 1.16.  However, we don't support 1.16 anymore.  But because that
fallback code is a "feature" in 1.18, we have to support it in 1.20.  But
that means that even when 1.18 is EOL... 1.20 still has the "feature"...
and thus we have to support it in 1.22.  And even when 1.20 is EOL... etc

We can never actually deprecate a feature, because by definition, every new
version will need to do what the old versions did.

On Wed, Apr 29, 2015 at 9:34 AM, Aaron Bentley <aaron.bentley at canonical.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2015-04-29 04:10 AM, roger peppe wrote:
> > On 28 April 2015 at 19:32, Aaron Bentley
> > <aaron.bentley at canonical.com> wrote:
> >> On 2015-04-28 11:42 AM, roger peppe wrote:
> >>> The .jenv code was introduced prior to 1.16. How far back in
> >>> time do we need to preserve compatibility? (genuine question)
> >>
> >> We need to support every mode of operation that 1.18 supported.
> >> Juju has a special exemption that allows minor releases, rather
> >> than micro/bugfix releases, to added to Ubuntu.  But in order to
> >> use that exemption, new versions of Juju are supposed to be
> >> equivalent to a micro/bugfix release in terms of their
> >> compatibility.
> >
> > So in general version 1.n will need to support every mode of
> > operation that version 1.n-1 supports? By induction doesn't that
> > mean we can never remove any features at all ever from Juju,
> > because every version will need to support every mode of operation
> > supported by *all* previous versions?
>
> No, only as long as 1.18 is in a supported release, i.e. until Trusty
> EOL.  But as William said, "I tend to abbreviate this in casual
> conversation as "forever""
>
> Once Trusty EOLs, then I think we would be able to drop functionality
> that 1.18 itself used only for migration.
>
> For example, if juju 1.18 had automatically created .jenvs from the
> environments.yaml instead of using environments.yaml directly, then
> when Trusty EOLed, we could drop that functionality.
>
> The other thing is that Juju 2.0 will not have this requirement.
>
> >> We had our own IS people upgrade to juju 1.20 from 1.18 and find
> >> that juju no longer worked.  That's terrible.
> >
> > Would it have been so terrible if the release notes had said "to
> > upgrade to juju 1.20, run this tool to transition your existing
> > local environment store first"?
>
> Yes.  People can upgrade from 1.18.4 to 1.20.11 using apt-get just by
> having the trusty-updates repository enabled.  They are not supposed
> to have to read release notes-- trusty-updates is supposed to be
> non-breaking changes.
>
> Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVQN35AAoJEK84cMOcf+9hs8cH+gMNGV4Glnp2gfqdomKPlzGd
> q92ukPLFFw8LL745OjGczn4Cy0BKqLT8kafMINKptx17MiC+vEHbuxnTNoHfrMKQ
> vqlUqzb7lwZMEc6s9j0iguFGJ/IjpF0tUeYOIZQst6lwPKlqUlA6KXhkCcvg3mh0
> IpBkCQDlkSUfgP8xLZLdIq0OyZls6WPBsrZmywT0+rfnimMNlJSc82gIs8HFmnfN
> blisw8Y721VywJyja+gvhhPM9ylwi4SvAaJ/s9+yVk8bEUmQe3YM567+LVqrf2Hz
> v3s46q5597BR0ECddUCIQYxATtDkSeU45RwdawHAHChosdJwXIVGGoSt9Ner5B4=
> =B7QT
> -----END PGP SIGNATURE-----
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150429/188b847c/attachment.html>