<div dir="ltr"><div>It is quite likely that many new charm features will only be exposed through the hook code, and not in any static metadata on the charm... so reliably determining a correct min juju version through static analysis is likely impossible.<br><br>Certainly, we can do our best effort and say "your min juju version definitely can't be lower than X because I see Y in your metadata.yml or I see hook Z"... but it's very possible that the correct min version is actually higher because of code used in the hooks.<br><br>In theory we could also have the testing infrastructure do a binary search of versions to find the right min version.... but I don't trust charm tests to be thorough enough to say passing tests == this actually works on this version.<br><br></div>It seems like this is what charm reviews are for, to catch people who just put the current juju version as their min version.<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 12:01 PM, Horacio Duran <span dir="ltr"><<a href="mailto:horacio.duran@canonical.com" target="_blank">horacio.duran@canonical.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ideally we will provide tools for the user to determine this, unless I understood wrongly the requirement.<br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 1:55 PM, Rick Harding <span dir="ltr"><<a href="mailto:rick.harding@canonical.com" target="_blank">rick.harding@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Then we should take up the burden to help others realize that their code will work with older versions of juju. Perhaps I am assuming, but if I am a charm author and I am wondering what my minimum version of juju is I will select the one I am currently using. Running tests and older versions are not something I'm going to do want to take up the burden on. This means that users of juju will have a smaller set of charms available to them because of this declaration even though it may actually work.</p>
<p dir="ltr">Rick</p>
<div class="gmail_quote"><div><div>On Dec 15, 2014 11:51 AM, "Nate Finch" <<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div>OK, so, many people in juju-core have talked about this with Eco, and we came to the conclusion that per-feature flags would be way too confusing for the charm consumer. When I want to deploy a charm, I don't wnat to have to figure out what version of juju supports leader election so I can know if the charm I want is supported by my version of juju. I just want to see a min version and compare it to my version of juju.<br><br>This does put a little more burden on charm authors, to do that translation themselves, but they would need to be able to do that anyway to understand what versions of juju support their charm. This way we at least take that burden off the person deploying the charm.<br><br></div>Also, we very specifically only support min version. This just means we'll need to be backwards compatible. There won't be leader election 2.0 that makes 1.0 not work.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 11:47 AM, Nate Finch <span dir="ltr"><<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">last copy of context to juju-dev<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard <span dir="ltr"><<a href="mailto:adam.collard@canonical.com" target="_blank">adam.collard@canonical.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>On 15 December 2014 at 15:06, Marco Ceppi <span dir="ltr"><<a href="mailto:marco.ceppi@canonical.com" target="_blank">marco.ceppi@canonical.com</a>></span> wrote:</span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm against this idea, what if something changes in the implementation of leader_election? Now there's a requirement to track version of features released and complexity grows. </div></blockquote><div><br></div></span><div>Well if that were to happen, the charm author would have to know which version of Juju they need anyway? In fact the version based tracking of this makes it even worse, let's for the sake of argument assume that leader election 1.0 comes in Juju 1.22.0 and leader election 2.0 comes in Juju 1.24.0. If the charm is using the "1.0 model" they have to say "I require Juju >= 1.22.0 and < Juju 1.24.0". In the capability model they simply state "I require a Juju capable of leader_election_2" (or some other better token that describes the change in a semantic way).<br><br></div><div>I think the capabilities based model can easily extend into a provider based constraint as well. So the charm can say "I require container addressing" and MAAS Provider will be fine but everything else will fail as per the current spec. Using a capabilities model is more expressive and can be extended. Using version numbers is clunky.<br></div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It seems much easier (testing and comprehension-wise) to have the author say "Won't work unless you have this version of Juju or higher". This makes testing, linting, and other typical charm author actions simpler while yielding virtually the same result.</div></blockquote><div><br></div></span><div>I don't think manually mapping features to Juju versions is simple for anyone now, let alone the expanded base of charm authors that we're targetting.<br><br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>As for your use case of "bugs in juju break user experience" is an already existent risk and can be improved in other ways that I think are outside the scope of this.</div></div></blockquote><div><br></div></span><div>Agreed.</div></div></div></div>
</blockquote></div></div>
</div></div></blockquote></div></div>
<br></div></div><span><font color="#888888">--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">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>
<br></font></span></blockquote></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">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>
<br></blockquote></div><br></div>
</div></div></blockquote></div></div>