juju min version feature

[Stuart Bishop]

On 16 December 2014 at 00:13, John Meinel <john at arbash-meinel.com> wrote:
> Can't we just as easily provide tools to find out what version of Juju
> provides a particular feature? Certainly a CLI of:
>  $ juju supported-features
>   leader-election
>   container-addressibility
>
> Or even possibly something that talks to something like the charm-store:
>  $ juju known-features
>  leader-election: juju >= 2.2
>  container-addressibility: juju >= 2.0
>
> I'm personally on the side of having charm *authors* talk about the features
> they want. Because then in juju-world we can enable/disable specific
> features based on them being requested, which makes charm authors get the
> features they need right. (e.g., if the charm doesn't say it needs
> leader-election, then it doesn't get leader tools exposed.)
>
> min-version, otoh, leads to people just setting it to the thing they are
> using, and doesn't give Juju a way to smartly enable/disable functionality.
> It also suffers from when we want to drop a feature that didn't turn out
> quite like what we thought it would.

On the flip side, I could state that I am developing my charm for juju
1.20 and not care what features I'm using. If someone deploys my charm
with juju 2.1, then juju could do so by deploying the charm in a 1.20
compatible environment. Juju devs can forge ahead and make backwards
incompatible changes to hook tools and the meanings of environment
variables by providing a compatibility layer.

I do think it is useful to encode the required juju version in the
charm. We also need versioning on interfaces (charms need to make
backwards incompatible changes to interfaces), and better support for
multiple charm series (1.0, 1.1, 2.0 vs 'trusty', 'precise'), but that
is all future spec work.

I think we need the required juju version even if we also allow people
to specify features. swift-storage could specify that it needs 'the
version of juju that configures lxc to allow loopback mounts', which
is a bug fix rather than a feature. Providing a feature flag for every
bug fix that a charm may depend on is impractical.

-- 
Stuart Bishop <stuart.bishop at canonical.com>