<div dir="ltr"><div>We’re looking in how we can identify 1.x Juju client/server in such a way that at the same time we don’t block access to charms for other clients using our HTTP API. </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 9:34 AM, Mark Shuttleworth <span dir="ltr"><<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.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 17/03/16 22:34, Nate Finch wrote:<br>
> Yes, it'll be ignored, and the charm will be deployed normally.<br>
><br>
> On Thu, Mar 17, 2016 at 3:29 PM Ryan Beisner <<a href="mailto:ryan.beisner@canonical.com">ryan.beisner@canonical.com</a>><br>
> wrote:<br>
><br>
>> This is awesome.  What will happen if a charm possesses the flag in<br>
>> metadata.yaml and is deployed with 1.25.x?  Will it gracefully ignore it?<br>
>><br>
<br>
</span>I wonder if there is a clean way for us to have Juju 1.x reject the<br>
charm very early in the process, giving an error that would essentially<br>
amount to the "not understood"? Or if we could have the charm store<br>
refuse to serve up the charm to a 1.x Juju client / server?<br>
<span class="HOEnZb"><font color="#888888"><br>
Mark<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</div></div></blockquote></div><br></div>