<br><br><div class="gmail_quote">On Tue, Jan 15, 2013 at 8:28 AM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Jan 9, 2013 at 10:30 PM, Kapil Thangavelu<br>
<<a href="mailto:kapil.thangavelu@canonical.com">kapil.thangavelu@canonical.com</a>> wrote:<br>
> That many semicolons makes me nervous ;-) Just to restate the changes then<br>
> are<br>
><br>
> 1. juju-* relation names are only valid for container require relations.<br>
><br>
> the existing preserved semantics<br>
><br>
> 2. juju-* interfaces or relation names can't be provided by a charm<br>
> 3. juju-* interfaces can be required by a charm.<br>
><br>
> Sounds good.<br>
<br>
</div>+1, plus adding a warn to cases matching (1) saying it is obsolete and<br>
should be avoided, and after a large enough grace period that we don't<br>
have to worry about right now, deprecating it with proper handling and<br>
reporting of errors.<br></blockquote><div><br></div><div>The issue with deprecation warnings is that it hits users not nesc the authors who can fix it. I think it would be odd for example to for someone deploying an gui in the charm to get hit by a deprecation warning. ie. Imagine if apps on your phone warned you about deprecated api usage by the app author.</div>
<div><br></div><div>We can audit the charm universe and file bugs against the charms exhibiting this problem. We can also classify them as a lint warning in the charm browser. </div><div><br></div><div>cheers,</div><div><br>
</div><div>Kapil</div></div>