previously valid amazon environment now invalid?

[roger peppe]

On 29 April 2015 at 12:40, William Reade <william.reade at canonical.com> wrote:
> 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 think you may have missed my point. Say we stop supporting 1.18.
Does that mean that we can remove support for the environment-fallback
feature (which is only there to support pre-1.16 functionality)? I don't think
it does, because 1.2x also implements that functionality and we still
need to support that too.

AFAICS this means we can never drop support for *any* feature,
no matter how long ago it was deprecated, regardless of which previous
versions we say we support.

>> 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.

The issue we're talking about is entirely client-side - it doesn't involve
the server at all. I accept the forever-backwardly-compatible
argument when we're talking about API compatibility, but I don't quite
see how your argument applies in this particular case.

 cheers,
    rog.