<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 29, 2015 at 10:10 AM, roger peppe <span dir="ltr"><<a href="mailto:roger.peppe@canonical.com" target="_blank">roger.peppe@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28 April 2015 at 19:32, Aaron Bentley <<a href="mailto:aaron.bentley@canonical.com">aaron.bentley@canonical.com</a>> wrote:<br>
> On 2015-04-28 11:42 AM, roger peppe wrote:<br>
>> The .jenv code was introduced prior to 1.16. How far back in time<br>
>> do we need to preserve compatibility? (genuine question)<br>
><br>
> We need to support every mode of operation that 1.18 supported.  Juju<br>
> has a special exemption that allows minor releases, rather than<br>
> micro/bugfix releases, to added to Ubuntu.  But in order to use that<br>
> exemption, new versions of Juju are supposed to be equivalent to a<br>
> micro/bugfix release in terms of their compatibility.<br>
<br>
</span>So in general version 1.n will need to support every<br>
mode of operation that version 1.n-1 supports? By induction<br>
doesn't that mean we can never remove any features at<br>
all ever from Juju, because every version will need<br>
to support every mode of operation supported by<br>
*all* previous versions?<br></blockquote><div><br></div><div>All supported previous versions, yes. Otherwise we're not really supporting them. This is not a new requirement.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd prefer to think that we can decide on a path forward,<br>
create migration tools if necessary, and eliminate old,<br>
confusing and velocity-impairing cruft from the code<br>
when possible. But I freely admit that I'm code-biased<br>
in this view :)<br>
<span class=""><br>
> We had our own IS people upgrade to juju 1.20 from 1.18 and find that<br>
> juju no longer worked.  That's terrible.<br>
<br>
</span>Would it have been so terrible if the release notes had said "to upgrade<br>
to juju 1.20, run this tool to transition your existing local environment<br>
store first"?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers</div><div>William</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  cheers,<br>
    rog.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br></div></div>