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
