copying some context to juju-dev
On Mon, Dec 15, 2014 at 10:06 AM, 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. 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. > > 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. > > Marco > > On Mon, Dec 15, 2014 at 10:00 AM, Adam Collard <adam.coll...@canonical.com > > wrote: >> >> So from an initial read of this spec, it seems like the plan is to >> provide a global numbering scheme and have charms that require a version >= >> some minimum. This feels like a bad idea, why not make it capability based? >> "I need a Juju that supports leader election" vs. "I need Juju 1.22" >> >> It not only gives a distinct set of keys (capability names) that make the >> requirement more expressive but also allows separates features from version >> numbers. It could also be expanded into something like "if >> juju.have_leader_election: ..." to allow charms to take advantage of a Juju >> feature but fallback on something in the charm if it's missing. >> >> I just think it might be a bit confusing if the charm were to say "I need >> Juju 1.22" but in reality there were some bug fixes which came out in Juju >> 1.22.3 and the charm won't even work (because of a Juju bug) in 1.22.0. >> >> Just my 2c :) >> >> On 15 December 2014 at 14:50, Horacio Duran <horacio.du...@canonical.com> >> wrote: >>> >>> Hello everybody, for those of you who don't know me, I am Horacio Duran, >>> I am part of Moonstone team on juju-core. >>> All of you have been signalled as stakeholders on juju's min version >>> feature. >>> Juju min version is intended to create charms that use newer features of >>> juju without breaking older jujus. >>> >>> This is a basic first version of the spec containing the stories we >>> believe define this feture. >>> Feel free to add comments into the doc, email me or even say "I dont >>> want to be part of this" or even if you feel anybody else should be here. >>> >>> Here is the link to the doc: >>> >>> https://docs.google.com/a/canonical.com/document/d/1vcpc1xLMdxvo_edMMlB2RS-h4I9eefkk5-a_Ey8ZoQE/edit# >>> >>> cheers. >>> >>
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
