previously valid amazon environment now invalid?

[William Reade]

On Wed, Apr 29, 2015 at 10:10 AM, roger peppe <roger.peppe at canonical.com>
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?
>

All supported previous versions, yes. Otherwise we're not really supporting
them. This is not a new requirement.

I'd prefer to think that we can decide on a path forward,
> create migration tools if necessary, and eliminate old,
> confusing and velocity-impairing cruft from the code
> when possible. But I freely admit that I'm code-biased
> in this view :)
>
> > 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, I think it would. It's not reasonable (or even possible, in the
general case) to have every user of a given environment upgrade their
client in lockstep with the environment; we'll *always* have to deal with
old-client/new-server, *and* vice versa, across a bunch of releases.
Compatibility code is frequently ugly, and heavy, but none of that makes it
any less critically necessary.

Cheers
William


>
>   cheers,
>     rog.
>
> --
> 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/cb562323/attachment.html>