juju min version feature

[Nate Finch]

It is quite likely that many new charm features will only be exposed
through the hook code, and not in any static metadata on the charm... so
reliably determining a correct min juju version through static analysis is
likely impossible.

Certainly, we can do our best effort and say "your min juju version
definitely can't be lower than X because I see Y in your metadata.yml or I
see hook Z"... but it's very possible that the correct min version is
actually higher because of code used in the hooks.

In theory we could also have the testing infrastructure do a binary search
of versions to find the right min version.... but I don't trust charm tests
to be thorough enough to say passing tests == this actually works on this
version.

It seems like this is what charm reviews are for, to catch people who just
put the current juju version as their min version.


On Mon, Dec 15, 2014 at 12:01 PM, Horacio Duran <horacio.duran at canonical.com
> wrote:
>
> Ideally we will provide tools for the user to determine this, unless I
> understood wrongly the requirement.
>
>
> On Mon, Dec 15, 2014 at 1:55 PM, Rick Harding <rick.harding at canonical.com>
> wrote:
>
>> 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.finch at 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.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.
>>>>>
>>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141215/26258ae6/attachment-0001.html>