juju min version feature

[Nate Finch]

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/a7558352/attachment.html>