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
