previously valid amazon environment now invalid?

[roger peppe]

On 29 April 2015 at 14:34, 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.

OK, this is interesting. So if we do actually want to get rid of this feature,
the steps would go something like:

- implement code in current juju-core so that
when the juju command needs an environment and the
.jenv file doesn't exist, the .jenv file is created.

- release that code as part of Ubuntu 16.04 Juju.

- for the 21.04 release (when we no longer support 16.04 support),
we can remove the fallback feature.

Is that about right? Or is even that not possible, because
the automatic .jenv creation is a feature in itself that
must be maintained?

Out of interest, how does this apply to command-line flag compatibility, where
there's no possible automatic migration?

  cheers,
    rog.