Ideally we will provide tools for the user to determine this, unless I understood wrongly the requirement.
On Mon, Dec 15, 2014 at 1:55 PM, Rick Harding <rick.hard...@canonical.com> wrote: > 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. > > Rick > On Dec 15, 2014 11:51 AM, "Nate Finch" <nate.fi...@canonical.com> wrote: > >> 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. >> >> 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. >> >> 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. >> >> On Mon, Dec 15, 2014 at 11:47 AM, Nate Finch <nate.fi...@canonical.com> >> wrote: >>> >>> last copy of context to juju-dev >>> >>> On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard < >>> adam.coll...@canonical.com> wrote: >>>> >>>> On 15 December 2014 at 15:06, Marco Ceppi <marco.ce...@canonical.com> >>>> wrote: >>>> >>>>> 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. >>>>> >>>> >>>> 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). >>>> >>>> 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. >>>> >>>> >>>>> 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. >>>>> >>>> >>>> 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. >>>> >>>> >>>>> 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. >>>>> >>>> >>>> Agreed. >>>> >>> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
