<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="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 class="h5">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 class="h5"><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 class="HOEnZb"><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">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>