Can't we just as easily provide tools to find out what version of Juju provides a particular feature? Certainly a CLI of: $ juju supported-features leader-election container-addressibility
Or even possibly something that talks to something like the charm-store: $ juju known-features leader-election: juju >= 2.2 container-addressibility: juju >= 2.0 I'm personally on the side of having charm *authors* talk about the features they want. Because then in juju-world we can enable/disable specific features based on them being requested, which makes charm authors get the features they need right. (e.g., if the charm doesn't say it needs leader-election, then it doesn't get leader tools exposed.) min-version, otoh, leads to people just setting it to the thing they are using, and doesn't give Juju a way to smartly enable/disable functionality. It also suffers from when we want to drop a feature that didn't turn out quite like what we thought it would. John =:-> On Mon, Dec 15, 2014 at 7:01 PM, Horacio Duran <[email protected]> wrote: > > 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 <[email protected]> > 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" <[email protected]> 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 <[email protected]> >>> wrote: >>>> >>>> last copy of context to juju-dev >>>> >>>> On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard < >>>> [email protected]> wrote: >>>>> >>>>> On 15 December 2014 at 15:06, Marco Ceppi <[email protected]> >>>>> 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 >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >>> >> -- >> Juju-dev mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
