juju min version feature

[Nate Finch]

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.finch at canonical.com>
wrote:
>
> last copy of context to juju-dev
>
> On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard <adam.collard at canonical.com
> > wrote:
>>
>> On 15 December 2014 at 15:06, Marco Ceppi <marco.ceppi at 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141215/8a63a6b9/attachment-0001.html>